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PREFACE 


This  document  was  prepared  by  the  Institute  for  Defense  Analyses  (IDA)  for  the 
Software  Data  Architecture  Engineering  Division,  Center  for  Computer  Systems  Engineering, 
Defense  Information  Systems  Agency  (DISA),  under  the  task  entitled  “Common  Operating 
Environment  Architecture”.  This  document  fulfills  these  task  objectives: 

•  To  provide  a  first-order  performance  model  and  associated  analysis  of  distributed 
computing  in  a  Client/Server  application. 

•  To  provide  guidance  to  technical  designers  and  developers  about  how  to  analyze  the 
performance  of  new  or  legacy  applications  in  order  to  engineer  or  re-engineer  them 
for  implementation  in  a  distributed  environment. 

The  following  IDA  research  staff  members  were  reviewers  of  this  document:  Dr.  Alfred 
E.  Brenner,  Dr.  Norman  R.  Howes  and  Dr.  Richard  J.  Ivanetich.  The  contributions  of  Mr.  David 
Diskin,  Ms.  Sherrie  Chubin,  and  Mr.  Steve  Stefanini,  all  of  DISA,  are  gratefully  acknowledged. 
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SUMMARY 


Purpose 

We  performed  a  series  of  experiments  to  provide  guidance  to  technical  designers  and 
developers  about  how  to  analyze  the  performance  of  new  or  legacy  applications  in  order  to 
engineer  or  re-engineer  them  for  implementation  in  a  distributed  environment.  We  used  lONA’s 
Orbix,  a  commercially  available  Object  Request  Broker  (ORB)  that  is  an  implementation  of  the 
Common  Object  Request  Broker  Architecture  (CORBA),  Version  2.0,  developed  by  the  Object 
Management  Group  (OMG)^  The  main  purpose  of  our  experiments  is  threefold: 

1.  To  understand  resource  expenditures  associated  with  distributing  objects 
between  clients  and  servers  that  communicate  using  remote  procedure  calls. 

2.  To  understand  performance  characteristics  of  distributed  object  computing 
using  a  simple  example  based  on  splitting  the  Global  Command  and  Control 
System  (GCCS)  Track  Correlation  Application  (TCA)  into  a  Track  Correlation 
Service  (TCS)  and  a  display  client. 

3.  To  provide  a  generic  process  for  evaluating  a  potential  design  of  a  distributed 
application  through  the  use  of  experimental  measurements. 

Background  and  Scope 

The  Defense  Information  Infrastructure  (DII)  Common  Operating  Environment  (COE) 
project  office  will  add  distributed  object  technology  products  to  future  releases  of  the  DII  COE. 
This  technology  will  implement  the  Object  Management  Group  (OMG)’s  Common  Object 
Request  Broker  Architecture  (CORBA),  Version  2.0,  and  Object  Management  Architecture 
(OMA).  This  technology  will  lead  to  new  design  considerations  which  will  have  a  large  poten¬ 
tial  impact  on  the  efficiency  of  applications. 

Our  set  of  experiments  will  enable  designers  and  developers  to: 

'  Some  timing  properties  will  be  similar  to  those  faced  when  using  other  distribution  products  based  on  the  Open 
Software  Foundation’s  Distributed  Computing  Environment  (DCE)  or  Microsoft’s  Distributed  Common  Object 
Model  (DCOM). 


•  Understand  the  feasibility  of  using  OMG’s  OMA  and  CORBA  as  the  software  infra¬ 
structure  for  Dn  COE-based  applications. 

•  Understand  the  effect  of  object  distribution  on  the  performance  of  DII  COE  based 
applications  and  services  due  to  changing  from  a  local  procedure  call  paradigm  to 
a  remote  procedure  call  paradigm. 

By  using  a  similar  set  of  experiments  based  upon  their  own  applications’  requirements, 
designers  and  developers  will  be  able  to: 

•  Develop  a  notion  of  granularity  using  the  ratio  of  computation  time  to  communica¬ 
tion  time. 

•  Develop  a  preliminary  understanding  of  potential  bottlenecks  in  the  systems  they 
design. 

•  Develop  insight  into  timing  latencies  and  dispersion  inherent  in  distributed  sys¬ 
tems. 

•  Establish  a  checklist  of  items  which  should  be  considered  in  the  design  and  devel¬ 
opment  of  applications. 

Model  and  the  Experiments 

Distributed  computing  technology  has  been  maturing  over  the  past  15  years.  In  the  dis¬ 
tributed  computing  environment,  Client/Server  computing  has  become  the  dominant  paradigm 
of  developing  distributed  applications.  Developers  are  responsible  for  providing  client  applica¬ 
tions  with  a  method  for  locating  appropriate  services  hosting  objects  acting  as  servers.  Using  a 
CORBA  Version  2.0  ORB,  client  objects  specify  the  desired  server  object  to  the  ORB  and  the 
ORB  determines  the  location  of  the  platforms  hosting  the  server  object,  ascertains  that  the  serv¬ 
er  object  exists  and  is  running,  and  causes  the  parameters  issued  by  the  client  to  be  presented 
to  the  server  hosting  the  service  and  then  to  the  desired  server  object.  Details  of  these  conve¬ 
niences  are  left  to  the  implementors  of  the  ORB  instead  of  the  developers  of  the  application. 
Thus,  in  the  model  of  computing  that  we  investigated,  there  are  a  client  object,  a  server  object, 
and  an  ORB. 

We  defined  a  timing  model  of  client  to  server  communications  for  both  a  local  proce¬ 
dure  call  (LPC)  paradigm  and  a  remote  procedure  call  (RPC)  paradigm,  the  latter  based  upon 
lONA’s  Orbix.  Orbix  offers  eight  points  where  we  can  measure  time  on  a  per-process  basis 
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Variation  in  the  latency  of  remote  communication. 


within  Orbix  library  code  in  a  convenient  fashion;  in  addition  there  are  other  points  where  we 
can  measure  time  in  the  clients  and  the  servers. 

We  performed  three  client  to  server  communications  experiments  —  communicating 
simple  integer  values,  communicating  a  938-byte  string  (representing  a  token  GCCS  track), 
and  communicating  a  VtPlatform  track  (representing  a  “real”  GCCS  track)  —  on  three  sets  of 
Client/Server  configurations:  Client  and  Server  objects  on  the  same  Sparc20,  Client  and  Server 
on  different  Sparc20s,  and  Client  on  Pentium  90  and  Server  on  Sparc20.  The  set  of  experiments 
assumes  that  stable  results  can  be  obtained.  Several  confounding  factors  that  are  explained  in 
this  report  can  invalidate  our  experiments  or  invalidate  their  interpretation.  These  were  mitigat¬ 
ed  to  the  extent  possible. 

Summary  of  Kev  Observations  and  Extrapolation 

On  a  Sun  Sparc20  hosting  both  client  and  server  processes,  a  LPC  which  does  no  server 
work^  costs  about  1.5  m/craseconds  (|xs);  an  Orbix  RPC  which  does  no  server  work  takes  about 
1.5  milliseconds  (ms),  or  about  1000  times  longer.  Communication  between  client  and  server 
objects  uses  about  1.3  ms  of  that  Orbix  RPC  time. 

Let  efficiency  be  defined  as  the  ratio: 

(LPC  Time  +  Server  Work  Time)/(RPC  Time  +  Server  Work  Time). 

In  order  to  achieve  50%  efficiency  using  RPC  in  this  case,  the  work  done  by  the  server  would 
have  to  take  more  than  the  time  taken  by  1000  LPCs  or  1.5  ms,  i.e.. 

Efficiency  =  (1+1000)  /  (1000+1000). 

In  order  to  achieve  90%  efficiency,  the  server  work  would  have  to  take  more  than  9000  LPCs 
(9  RPCs)  or  13.5  ms.  This  leads  to  the  conclusion  that  procedures  which  are  to  be  executed 
remotely  on  a  Sparc20  should  have  sufficiently  large  granularity  (very  much  greater  than  1 
ms)  in  order  to  amortize  the  inefficiency  of  RPC.  Even  larger  granularity  may  be  required  to 
amortize  other  CORBA/Orbix  inefficiencies. 

Substantial  time  is  used  by  communication  between  client  and  server  objects:  1.3  ms 
with  very  small  messages  in  each  direction  on  the  Sparc20  when  client  and  server  processes  are 


^  This  is  the  time  required  to  ping  the  server.  To  avoid  confusion,  the  term  “server  work”  will  be  used  to  refer  to 
the  work  performed  by  the  called  entity  whether  that  entity  is  called  by  LPC  or  RPC.  Client  work  will  refer  to 
the  work  that  the  client  performs  on  the  results  provided  by  the  server. 


hosted  on  the  same  machine.  More  time  is  expended  if  the  network  is  used.  Substantial  addi¬ 
tional  time  is  required  for  handling  heterogeneity,  e.g.,  for  assembling  and  converting  strings 
or  structures  for  transmission. 

Based  upon  our  experiments  using  Orbix  2.0.1  and  Solaris  2.5  for  casual  browsing  of  a 
database  on  a  record  by  record  basis,  a  Sparc20  used  to  host  a  server  process  may  provide 
enough  capability,  but  for  intensive  updating  of  information  by  a  number  of  clients,  it  is  unlike¬ 
ly  that  the  Sparc20  will  provide  sufficient  computing  power  to  accomplish  the  job,  as  the  fol¬ 
lowing  illustrative  examples  demonstrate. 


Examples  Derived  from  Measurements 

Suppose  we  wished  to  divide  the  GCCS  Track  Correlation  Application  into  a  client  and 
a  server  where  track  updates  occur  at  a  rate  of  1000  per  second.  We  might  naively  divide  such 
an  application  into  a  display  client  and  a  track  correlation  service  (TCS)  which  accesses  a 
record  in  a  database.  Assume  that  tracks  are  stored  in  a  memory  cache,  and  that  information  is 
disseminated  using  RPC  based  on  the  API  used  to  access  the  database  of  the  current  GCCS 
Track  Correlation  Application. 


The  One  Client  Case 


Display  Client 

Pentium  90  ^ 

L 

Correlation  Server 


0.5ms 


Sparc20 


Communications 


6.0  ms  Roundtrip 


Figure  1.  One  Client 


Suppose  that  the  Sparc20  Server  process  could  retrieve  a  record  of  1000  bytes  in  0.5 
ms^  from  a  database  cached  in  memory  for  use  in  the  same  process.  Obtaining  that  record  using 
a  Pentium  90  as  client  by  means  of  RPC  would  add  an  additional  6  ms^  for  a  total  of  6.5  ms. 
The  maximum  number  of  serial  reads  per  second  is  (1  second  /  0.065  seconds)  or  about  150  per 


A  hypothetical  time  for  cached  database  access. 

^  Drawn  from  the  data  of  Pentium90-based  Client  and  SPARC-based  Server. 


second  for  this  client,  assuming  that  the  client  obtains  a  record,  displays  it,  then  obtains  another 
record,  displays  it,  and  so  forth.  Using  this  simple  design  we  cannot  achieve  the  goal  of  1000 
updates  per  second. 


The  Multi-Client  Case 


Figure  2.  Multiple  Clients 

A  second  example:  Suppose  the  total  time  used  by  the  server’s  host  Sparc20  for  each 
client’s  request  for  a  record  was  1.5  ms  including  the  read.^  Five  ms^  is  spent  on  the  client  plat¬ 
form,  resulting  in  a  total  roundtrip  time  of  6.5ms.  Then  the  maximum  number  of  records  per 
second  which  might  be  obtained  in  a  simple  request-response  pattern  from  this  server  using  a 
cached  database  would  be  on  the  order  of  (1  second/  0.0015  second)  or  approximately  666 
requests  per  second  —  thus  it  could  only  support  four  Pentium  90  display  clients  at  approxi¬ 
mately  166  requests  per  second  each. 

We  conclude,  based  upon  our  observations,  that  a  naive  division  of  the  GCCS  Track 
Correlation  Application  into  a  client  and  database  service  on  Pentium  90s  and  Sparc20s  using 
Orbix  2.0. 1  is  unlikely  to  be  successful  because  of  the  computing  and  communication  overhead 
required  for  distribution  of  the  client  and  server.  It  remains  to  be  seen  whether  a  different  strat¬ 
egy  such  as  simultaneous  transmission  of  multiple  tracks  would  better  utilize  the  processor  so 
that  the  server  work  could  be  done  in  the  time  required.  Design  strategies  must  also  be  recon- 


^  Assuming  that  none  of  the  time  is  spent  waiting  and  based  on  timing  of  the  SPARC20-based  Server. 
^  Based  on  a  roundtrip  time  of  6.5  ms  including  the  data  access  minus  1.5  ms  server  time. 


sidered  if  you  use  a  higher  performance  processor,  a  different  or  improved  ORB/IDL/Library 
combination  featuring  a  better  implementation  of  communications. 

Recommendations 

Based  upon  our  experiments,  we  recommend  that  designers  or  developers  should  care¬ 
fully  consider  the  timing  properties  of  the  delivery  platform(s)  and  of  the  software  infrastruc¬ 
ture  during  the  design  of  any  distributed  application: 

•  Developers  should  create  a  simple  prototype  from  which  they  will  gain  the  informa¬ 
tion  required  for  their  design.  For  the  targeted  client  and  server  platforms,  designers 
should  employ  the  hardware  and  software  which  will  support  the  delivered  applica¬ 
tion.  Designers  should  determine  the  time  to  marshal^  and  unmarshal  the  data  struc¬ 
tures  to  be  used.  In  addition  they  should  measure  the  amount  of  communications 
time  taken  by  each  different  kind  of  remote  procedure  call  and  the  amount  of  time 
required  to  service  each  request.  This  should  lead  to  a  mathematical  model  of  the 
amount  of  resources  required  to  perform  each  kind  of  request.  These  times  can  also 
be  used  in  simulations  of  the  applications  to  be  designed. 

•  Designers  or  developers  should  give  speeial  attention  to  the  following  factors: 

Carefully  consider  the  amount  of  computation  to  be  done  on  the  server  for  each 
request.  Too  little  computation  on  the  server  reduces  the  overall  effieiency  of 
computation  because  of  the  communications  overhead.  If  the  overhead  of  a 
remote  request  is  too  high,  implement  the  service  as  a  library  or  collection  of 
classes  using  LPC  instead. 

Carefully  consider  the  type  of  argument(s)  to  be  passed  to  the  server  or 
returned  to  the  client.  Try  to  make  the  argument  as  simple  and  as  aligned  as 
possible.  Attempt  to  find  an  implementation  of  IDL  that  can  perform  marshal¬ 
ling,  unmarshalling,  and  service  in  parallel,  using  threads.  This  is  particularly 
valuable  if  the  service  performs  I/O  operations. 

-  For  computationally  intensive  services  that  can  be  parallelized,  consider  using 
multiple  servers  and  distributing  the  computation  (servers)  on  multiple  plat¬ 
forms.  Also  try  to  hide  communications  latencies  by  using  multi-threaded  serv¬ 
ers  to  handle  multiple  requests  in  a  pipelined  fashion.  Find  the  sum  of  times  on 
the  paths  which  must  be  performed  serially.  This  is  the  optimum  time  which 
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See  the  body  of  the  paper  or  glossary  for  definition  of  technical  terms  such  as  marshalling  and  unmarshalling. 


can  be  achieved  [one  of  Amdahl’s  laws].  One  may  think  that  using  many 
machines  executing  a  task  in  parallel  pieces  will  reduce  the  total  computation 
time,  but  the  overhead  introduced  by  the  communication  must  be  taken  into 
account.  Verify  that  the  time  for  using  multiple  servers  is  shorter  than  running 
the  calculation  on  a  single  machine  using  LPC. 

-  Carefully  consider  the  factors  which  could  render  the  experimental  results 
invalid  such  as  requests  causing  conununications  to  other  servers  on  the  same 
host.  Determine  if  they  will  contribute  to  your  client-server  workload.  Espe¬ 
cially  consider  the  number  of  requests  per  second  to  database  servers  and  the 
amount  of  I/O  operations  these  servers  are  expected  to  perform. 

-  Carefully  consider  the  confounding  factors.  Try  to  characterize  them  in  order 
to  determine  if  they  will  contribute  to  your  client/server  workload.  If  they  will, 
identify  mitigation  strategies.  Especially  consider  the  number  of  requests  per 
second  to  database  servers  and  the  amount  of  I/O  these  servers  are  expected  to 
do. 

As  has  been  suggested  in  the  illustrative  examples,  results  vary  depending  on  many  fac¬ 
tors.  What  is  important  is  to  experiment  and  model  during  design  to  determine  what  factors  are 
most  significant  and  what  can  be  done  to  improve  performance. 


CHAPTER  1.  INTRODUCTION 


1.1  PURPOSE 

This  paper  gives  guidance  to  technical  designers  and  developers  about  how  they  can 
analyze  the  performance  of  legacy  or  new  applications  in  order  to  re-engineer  them  for  imple¬ 
mentation  in  a  distributed  object  environment  using  the  Object  Management  Group  (OMG)’s 
Common  Object  Request  Broker  Architecture  (CORBA)^  New  distributed  object-  or  proce¬ 
dure-oriented  applications  may  also  benefit  from  this  methodology  which  is  based  upon  con¬ 
ducting  and  utilizing  the  results  of  a  series  of  experiments.  Our  experiments  were  made  using 
lONA’s  Orbix,  a  commercial  Object  Request  Broker  (ORB)  compliant  with  CORBA,  Version 
2.0.  The  main  purpose  of  our  experiments  is  threefold: 

1 .  To  understand  resource  expenditure  required  to  support  distributed  computing 
for  the  purpose  of  distributing  objects  optimally  between  clients  and  servers  that 
communicate  using  remote  procedure  call. 

2.  To  understand  performance  characteristics  of  distributed  object  computing 
using  a  simple  example  based  on  splitting  the  Global  Command  and  Control 
System  (GCCS)  Track  Correlation  Application  (TCA)  into  a  Track  Correlation 
Service  (TCS)  and  a  display  client. 

3.  To  provide  a  generic  process  for  evaluating  a  potential  design  of  a  distributed 
application  through  the  use  of  experimental  measurements. 

A  simple  example  will  be  used  to  show  the  kind  of  analyses  which  must  be  done  before 
dividing  an  application  into  clients  and  servers  and  before  attempting  to  decide  on  which  plat¬ 
forms  to  place  client  and  server.  The  example:  dividing  the  GCCS  Track  Correlation  Applica¬ 
tion  into  display  client  and  track  correlation  server  using  the  current  track  correlation  database 
interface,  while  naive,  is  typical  of  the  so-called  “two-tier”  approach  where  a  client  directly 
uses  a  data  base  by  calling  its  interface  API.  It  is  not  the  intent  of  the  paper  to  suggest  that  this 
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Some  of  these  considerations  will  be  similar  to  those  faced  when  using  other  distribution  products  based  on  the 
Open  Software  Foundations’  Distributed  Computing  Environment  (DCE)  or  Microsoft’s  Distributed  Common 
Object  Model  (DCOM). 


is  the  appropriate  division  of  the  TCA.  It  is  the  intent  of  the  paper  to  use  this  example  to  moti¬ 
vate  the  experiments  which  were  performed  and  to  sketch  the  difficulties  that  such  a  design 
would  face. 

1.2  AUDIENCE 

This  paper  is  intended  for  technical  designers  and  developers  who  must  design  distrib¬ 
uted  object  applications  using  CORBA  and  OMA  or  for  others  who  would  like  to  understand 
the  feasibility  of  applications  in  a  distributed  object  environment. 

1.3  OUTLINE  OF  PAPER 

The  paper  is  divided  into  four  major  sections,  exclusive  of  the  introduction: 

1.  Introduction  —  describes  the  objectives  of  the  study  and  the  benefits  to  be 
derived  from  it. 

2.  Methodology  —  describes  the  framework  for  experimentation. 

3.  Results  of  Measurement  —  provides  the  results  of  the  experiments  in  detail. 

4.  Summary  of  Observations  —  summarizes  what  was  discovered  and  attempts  to 
generalize  the  results. 

5.  Recommendations  for  Design  —  provides  a  process  for  developers  of  distribut¬ 
ed  applications  and  a  checklist  of  considerations  for  designers. 

1.4  OBJECTIVES  OF  THE  EXPERIMENTS 

The  Defense  Information  Infrastructure  (DII)  Common  Operating  Environment  (COE) 
project  office  intends  to  add  distributed  object  technology  to  future  releases  of  the  COE  which 
will  support  an  object-oriented  distributed  computing  paradigm.  This  technology  will  employ 
software  based  on  the  consortium  specifications  known  as  the  Object  Management  Group 
(OMG)’s  Common  Object  Request  Broker  Architecture  (CORBA),  Version  2.0^  and  the 
OMG’s  Object  Management  Architecture^  (OMA).  The  technology  will  lead  to  new  consider¬ 
ations  for  design  which  will  have  a  large  potential  impact  on  the  efficiency  of  systems  devel¬ 
oped  using  this  technology. 


^  Object  Management  Group.  1996.  Common  Object  Request  Broker  Architecture,  Revision  2.  Object  Manage¬ 
ment  Group,  Framingham,  MA.  01701.  July  1996 

^  Object  Management  Group.  1990.  Object  Management  Architecture  Guide,  Revision  1 .0.  Object  Management 
Group,  Framingham,  MA.  01701.  November  1, 1990. 


The  set  of  experiments  which  were  conducted  are  designed  to  help  designers: 

•  Understand  the  effect  of  object  distribution  on  the  design  of  DII  COE  based  appli¬ 
cations  and  services. 

•  Understand  the  effect  of  changing  from  local  procedure  call  (LPC)  to  remote  pro¬ 
cedure  call  (RPC)  on  design  of  applications. 

•  Understand  the  feasibility  of  using  OMG’s  OMA  for  specific  applications  of  impor¬ 
tant  subdomains  such  as  the  Global  Command  and  Control  System  (GCCS)  includ- 

« 

ing  TCS. 


1.5  BENEFITS  TO  DII  COE  DEVELOPERS  AND  COMMUNITY 

By  using  a  similar  set  of  experiments  based  upon  their  own  application ’s  requirements 
and  concept  of  operations,  designers  and  developers  of  distributed  object  systems  based  on 
CORBA  will  be  able  to: 

•  Develop  a  notion  of  granularity  using  the  ratio  of  computation  time  to  communica¬ 
tion  time. 

•  Develop  a  preliminary  understanding  of  potential  bottlenecks  in  the  systems  they 
design. 

•  Develop  insight  into  timing  latencies  and  dispersion  inherent  in  distributed  systems. 

•  Establish  a  checklist  of  items  which  should  be  considered  in  the  design  and  devel¬ 
opment  of  distributed  applications. 


CHAPTER  2.  METHODOLOGY 


2.1  INTRODUCTION  TO  DISTRIBUTED  COMPUTING 

Distributed  computing  technology  has  been  maturing  over  the  last  15  years.  Originally, 
each  solution  was  handcrafted,  using  whatever  communication  mechanisms  were  available. 
Later,  low  level  communication  services  were  standardized.  The  Berkeley  community  chose 
sockets  and  the  Bell  Labs  community  chose  the  Transport  Layer  Interface(TLI).  Next,  RPC 
was  used  to  hide  the  complexity  of  socket  programming  and  to  make  distributed  programming 
obey  the  well-known  procedure  call  semantics.  RPC  had  higher  overhead  than  socket  program¬ 
ming  but  was  much  easier  to  use.  Application-oriented  languages/systems  such  as  Linda‘S  per¬ 
mitted  programmers  to  develop  applications  that  were  of  large  granularity  and  computationally 
intensive  with  few  data  dependencies  which  could  be  executed  in  parallel  on  multiple  machines 
using  RPC. 

In  the  late  1980s,  the  Open  Software  Foundation  (OSF),  now  part  of  the  Open  Group 
(OG),  developed  a  framework  for  distributed  computing  called  the  Distributed  Computing 
Environment  (DCE)  which  utilized  RPC  to  access  a  set  of  standardized  services.  These  services 
included  security,  time,  and  directory  services  among  others.  A  complex  application  program¬ 
ming  interface  (API)  was  delivered  in  the  early  1990s  which  permitted  the  development  of  dis¬ 
tributed  applications  of  high  complexity  and  which  facilitated  optimization  of  those 
applications.  An  example  of  one  of  those  applications  is  the  Distributed  File  System  (DFS) 
which  features  replication,  access  control  lists,  and  distributed  management  tools.  Another  is 
Transarc’s  Encina®,  a  transaction  manager.  DCE  utilizes  procedural  access  to  services. 

In  1990  the  Object  Management  Group  was  formed  to  promote  distributed  computing 
based  upon  the  premise  that  all  computing  would  be  utilizing  an  object  paradigm.  Goals  of  this 
new  mode  were:  location  transparency;  heterogeneity  of  platform,  operating  system,  and  pro¬ 
gramming  language;  and  access  via  standardized  interface.  Where  DCE  programming  was  at 
an  inherently  lower  level  of  detail,  OMG’s  object  programming^  was  at  a  level  much  closer  to 
the  application:  the  object  request  broker  (ORB)  was  to  hide  many  of  the  small  details  typical 
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See  http://www.sca.coin/linda.htinl. 


of  DCE  programming.  Object  services  were  to  be  specified  that  would  provide  a  rich  set  of 
reusable  components 

In  the  DCE  world  of  Client/Server  computing,  programmers  are  responsible  for  deter¬ 
mining  where  Servers  for  their  Clients  reside,  either  using  end-point  mappings,  a  local  direc¬ 
tory  service,  or  a  remote  directory  service.  In  the  ORB  world,  one  specifies  the  desired  service 
to  the  ORB  using  an  object  reference,  and  the  ORB  determines  the  location  of  the  service, 
ascertains  that  it  exists  and  is  running,  and  causes  the  parameters  issued  by  the  Client  object  to 
be  presented  to  the  desired  object  within  the  service  that  instantiates  the  object.  Details  of  these 
conveniences  are  left  to  the  implementors  of  the  ORB,  instead  of  the  developers  of  the  appli¬ 
cation. 

Thus  in  the  model  of  computing  to  be  investigated,  there  is  an  object  with  role  of  Client, 
an  object  with  role  of  Server,  and  an  ORB.  The  application  we  will  investigate  is  a  repetitive 
query  in  which  the  Client  repeatedly  interrogates  the  Server  for  the  latest  data  values,  waiting 
for  a  set  of  values  to  be  delivered  before  asking  for  the  next  set.  In  the  implementation  to  be 
tested;  Orbix  2.0. 1  for  Solaris  and  Orbix  2.02  for  Microsoft  NT,  the  ORB  is  only  involved  in  a 
few  of  the  communications.  The  Orbix  ORB  determines  the  location  of  the  Server  for  the  Cli¬ 
ent,  and  initializes  the  service  if  necessary;  then  it  mediates  the  selection  of  connection-orient¬ 
ed  communication  paths  (transmission  control  protocol  on  internet  protocol  (TCP/IP)  sockets) 
from  Client  to  Server  (and  vice-versa)  in  communications  1-8  (See  Figure  3).  Until  the  Client 
decides  to  close  the  connection  to  the  service,  the  connection  between  Client  and  service  is 
maintained  by  the  communications  software.  In  the  event  that  the  Server  fails,  a  Client  request 
will  return  an  exception.  In  this  case  the  Client  must  request  that  the  ORB  reinitialize  the  failed 
server  or  locate  another  server  and  initialize  communication  with  it.  Our  experiments  will 
assume  a  failure  free  situation  for  simplicity.  In  our  use  almost  all  the  traffic,  generated  by  Cli¬ 
ent  method  invocations,  proceeds  from  Client  to  Server  to  Client  over  the  mediated  socket  con¬ 
nection  provided  by  the  ORB.  Since  the  Server  can  support  multiple  objects,  a  dispatcher 
provided  by  the  Orbix  Library  code  on  the  Server  platform  uses  the  object  reference  to  deter¬ 
mine  which  object  hosted  by  the  server  is  being  queried  and  which  method  of  the  interface  to 
that  object  is  being  called  and  dispatches  to  it. 


^  OMG’s  object  paradigm  is  interface  based,  utilizing  RPC  to  invoke  methods  of  objects  which  “hide  behind” 
their  interface. 


Assuming  that  there  is  a  long-lived  connection  between  Client  and  Server,  we  might 
wish  to  focus  our  attention  on  the  communication  between  the  Client  and  the  Server  in  com¬ 
munications  9,  10,  11,  12, ...  (unless  the  ORB  is  exceptionally  slow)  in  the  analysis  of  distrib¬ 
uted  object  computing^.  If  only  a  few  requests  are  issued  for  a  service,  we  would  focus  attention 
on  the  time  required  for  mediation  by  the  ORB  and  on  the  cost  of  opening  and  closing  connec¬ 
tions.  Such  would  be  the  case  if  we  were  designing  a  collaborative  planning  or  network  brows¬ 
ing  application.  In  that  case  the  nature  of  the  experimental  investigation  would  be  different. 

Since  our  example  primarily  demonstrates  the  communication  between  Client  and 
Server,  we  note  that  the  difference  between  the  distributed  and  the  non-distributed  case  is  the 
use  of  Remote  Procedure  Call  (RPC)  in  the  former  case  and  Local  Procedure  Call  (LPC)  in  the 
latter  case.  We  can  define  relative  efficiency  to  be  the  ratio  of  the  time  taken  for  the  RPC  +  Serv¬ 
er  Work^  to  that  of  LPC  +  Server  Work.  Figure  4  and  Figure  5  illustrate  a  model  of  the  two 
cases. 


^  Under  some  circumstances,  the  Client  might  bind  itself  to  an  object  in  the  Server,  request  a  few  invocations, 
and  then  disconnect,  possibly  reconnecting  later.  In  our  examples,  the  Client  would  connect  once  and  remain 
connected  for  a  very  substantial  period. 

To  avoid  confusion,  the  term  “server  work”  will  be  used  to  refer  to  the  work  performed  by  the  called  entity 
whether  that  entity  is  called  by  LPC  or  RPC.  Client  work  will  refer  to  the  work  that  the  client  performs  on  the 
results  provided  by  the  server. 


Figure  4.  Local  Procedure  Call 


Eqn.  1:  '^\lpc  ~  ''"\calun)'^'^\service'^^\return{M) 


Let  x|x  be  the  amount  of  time  taken  for  the  part  of  the  local  procedure  call  labeled  x, 
then  the  time  for  a  local  procedure  call  is  given  by  Equation  1  above,  where  N  represents  the 
number  of  bytes  transferred  by  the  caller  and  M  represents  the  number  of  bytes  returned  by  the 
service.  Figure  4  is  incorrect  for  system  calls  because  the  typical  operating  system  call  involves 
the  use  of  different  address  spaces:  the  system  address  space  and  the  application  address  space. 
The  reason  this  is  important  is  that  “call  by  reference”  can  be  employed  within  the  same  address 
space,  but  that  “call  by  value”  must  be  used  between  two  different  address  spaces.  The  latter 
requires  the  allocation  of  space  and  copying  of  values  which  may  involve  significant  overhead.® 
It  also  may  require  two  process  exchanges  to  give  the  hardware  access  to  the  new  address  space 
and  to  return  and  may  result  in  multiplexing  the  use  of  resources.  The  use  of  local  procedure 
call  within  a  single  address  space  is  the  least  expensive  of  all  service  use  in  terms  of  time 
expended. 


*  A  typical  local  procedure  call  on  a  Sun  SPARC20  (75Mhz)  requires  1  microsecond  whereas  a  typical  instruc¬ 
tion  may  require  but  2  nanoseconds  and  a  process  exchange  100  nanoseconds. 
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Remote  Procedure  Call  is  the  most  expensive  use  of  time.  It  is  illustrated  in  Figure  5. 


Figure  5.  Remote  Procedure  Call 


In  this  case  there  are  two  address  spaces  involved,  potentially  on  two  different  machines.  The 
Client  and  software  which  acts  as  proxy  for  the  Server  are  in  one  address  space  and  software 
which  acts  as  a  proxy  for  the  Client  and  the  Server  are  in  a  second  address  space,  potentially 
on  a  different  machine.  The  following  is  the  conceptual  sequence  by  which  remote  procedure 
call  is  accomplished: 

•  The  Client  calls  the  proxy  for  the  Server  and  provides  arguments  to  it,  either  by  val¬ 
ue  or  by  reference  because  it  is  in  the  same  address  space. 

•  The  proxy  for  the  Server  marshals  the  arguments,  i.e.,  it  obtains  the  values  for  the 
N  bytes  of  arguments,  converts  them  to  a  standard  representation,  following  stan¬ 
dard  alignment  rules  which  may  require  padding  with  null  bytes.  Then  it  passes  this 
set  of  N  bytes  (which  probably  will  be  larger  than  N)  to  the  circuit  based  commu¬ 
nication  protocol  (in  this  case  TCP/IP  sockets)  which  reliably  forwards  the  message 
along  with  P  protocol  bytes  to  the  socket  on  the  other  platform. 

•  The  N  bytes  are  received  by  the  proxy  for  the  Client  which  unmarshalls  the  argu¬ 
ments:  i.e.,  it  converts  the  bytes  from  standard  form  and  alignment  to  N’  bytes  of 
the  proper  form  and  alignment  for  the  second  platform. 

•  The  proxy  for  the  Client  then  calls  the  object  that  the  Server  has  made  available  to 
the  Client,  selects  the  method  specified  by  the  Client,  and  calls  this  method  using 


the  N’  bytes  of  arguments  supplied  by  the  Client  using  a  local  procedure  call  which 
may  be  either  by  value  or  by  reference. 

•  The  service  performs  its  computation,  returning  its  result  of  M’  bytes  to  the  proxy 
for  the  Client. 

•  The  proxy  for  the  Client  marshals  the  returned  values  into  a  data  structure  of  M 
bytes  which  it  passes  through  the  communications  protocol  with  Q  protocol  bytes 
to  the  socket  on  the  Client’s  platform. 

•  There  the  proxy  for  the  service  unmarshalls  the  returned  value  and  returns  these  M 
bytes  to  the  Client. 

The  timing  equation  for  RPC  is  as  follows: 

Eqn.  2: 


'^\rpc  '^\calun) 

+  tI  +  t 

\RETURN{M') 


+  T  —  +T  —  +T  —  +T  +T 

\Marshal(N)  \Send{N  +  P)  lUnmarshal(N)  iCALL(N') 

Marshal(M)  +  Q)  \unmarshal(M)  \rETURN(M) 


SERVICE 


It  conveniently  omits  the  detail  of  additional  overhead  which  may  be  added  utilizing  the  level 
of  security  which  may  be  desired.  For  example,  if  we  desire  confidentiality,  time  for  encryp¬ 
tion  and  decryption  must  be  added.  If  we  want  to  guarantee  integrity  of  messages,  integrity 
bits  must  be  generated  and  added  to  the  message  and  must  be  checked  at  the  receiver.  If  the 
Client  and/or  Server  do  not  trust  one  another,  additional  time  must  be  added  for  the  purpose  of 
authentication.  These  additional  times  are  shown  in  Equation  3. 

Eqn.  3: 


r  =  T  +x  —  +x  _  +x  _ 

iRPC  \CALL(N)  MarshaHN)  Send{N  +  P)  Unmarshal(N) 
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RETURNiM') 
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-f-Xl  _  +T  _ 

Send(M  +  Q)  Unmarshal(M) 


+  X\  +X  _  +T  _  -t- X  _ 

iRETURN(M)  \lntegrityGenerate{N)  ilntegrityCheck(N)  \lntegrityGenerate{M) 

-l-X|  ,  _  +X|  _  +X|  _  -^X|  _  -l-X|  _ 

UntegrityCheck(M)  >Encrypt(N)  iDecrypt(N)  lEncrypt(M)  \Decrypt{M) 

+  x|  +  x| 

I  Authenticate  Client  \AuthenticateServer 


We  note  that  in  the  simple  case  of  RPC  (Equation  2)  we  have  two  calls  and  two  returns. 
There  are  also  fixed  overheads  of  two  marshals  and  two  unmarshals  plus  a  fixed  time  compo¬ 
nent  associated  with  send  and  a  variable  component  associated  with  send  but  actually  related 
to  latencies  due  to  scheduling  processes  on  the  platforms  which  host  the  Client  and  Server 


objects.  The  time  for  send  is  inclusive  of  both  the  fixed  and  the  variable  times.  The  figure  in 
Appendix  B,  Attachment  3  shows  the  ratio  between  LPC  +  Server  Work  and  RPC  +  Server 
Work  as  a  function  of  the  time  required  for  the  work  on  the  Server.  As  can  be  seen,  the  more 
time  taken  in  the  service,  the  higher  the  relative  efficiency. 

In  order  to  get  a  better  idea  of  the  actual  efficiency,  it  will  be  necessary  to  measure  actual 
overheads  in  several  styles  of  implementations.  Ideally,  we  would  determine  the  actual  times 
for  a  specific  service  and  there  would  be  no  variation.  In  practice  we  will  not  be  able  to  do  this, 
but  we  will  be  able  to  determine  “general  orders  of  magnitude”  which  will  help  us  design  appli¬ 
cations  for  which  our  experiments  are  relevant. 

2.2  BUILDING  THE  TIMING  AND  DATA  MODELS 

In  building  a  timing  model,  we  need  to  understand  where  we  can  measure  and  the  accu¬ 
racy  to  which  time  may  be  measured.  A  CORBA  compliant  ORB,  Iona  Orbix  2.x  has  been 
specified  for  use  in  the  DII  COE.  Orbix  offers  eight  places  (Points  1-8  in  Figure  6)  where  time 
can  be  measured  on  a  per-process  basis  in  a  convenient  fashion^;  in  addition  there  are  other 
points  (e.g.,  Points  0  and  9  in  Figure  6)  where  we  can  measure  time  in  the  Client  or  in  the  Serv¬ 
er.  Points  0-9  in  Figure  6  are  used  in  our  experiments.  In  addition  points  10  and  1 1  mark  places 
where  the  number  of  bytes  used  in  communication  are  measured.  The  times  at  which  events  are 
measured  and  the  number  of  bytes  transmitted  are  denoted  as  indicated  by  the  following  list. 

0.  In  the  Client  object,  Tq. 

1.  Prior  to  the  point  that  the  proxy  for  the  Server  marshals  the  arguments,  Xj . 

2.  After  the  proxy  for  the  Server  has  marshalled  the  arguments,  T2- 

3.  Prior  to  the  point  that  the  proxy  for  the  Client  unmarshals  the  arguments,  X3. 

4.  After  the  proxy  for  the  Client  has  marshalled  the  arguments,  X4. 

5.  Prior  to  the  point  that  the  proxy  for  the  Client  marshals  the  arguments,  X5. 

6.  After  the  proxy  for  the  Client  has  marshalled  the  arguments,  X5. 

7.  Prior  to  the  point  that  the  proxy  for  the  Server  unmarshals  the  arguments,  X7. 

8.  After  the  proxy  for  the  Server  has  unmarshalled  the  arguments,  tg. 

^  Orbix  allows  interception  on  a  per  object  or  per  process  basis.  Since  our  service  has  only  one  “object”  we  will 
use  the  per  process  interception.  Using  it  we  also  see  all  requests  of  the  Client  process  to  the  ORB  and  the  ORB 
process  to  the  Server  process.  These  requests  result  in  the  initialization  and  destruction  of  the  communication 
paths  between  Client  and  Server. 


9.  In  the  Server  object,  X9. 

10.  Total  number  of  bytes  transmitted  by  the  Server  proxy,  B1 

1 1 .  Total  number  of  bytes  transmitted  by  the  Client  proxy,  B2 


I - 1  r - — - —  —  —  —  —  —  —  1 

I  Address  Space  A  I  I  Address  Space  B  I 

I  Processor  1  I  I  Processor  2  I 


I  Proxy  I  I  Proxy  I 

I _ I  I _ _ _ _ I 

Figure  6.  Experimental  Monitoring  Points 

Note  that  the  time  for  marshalling  can  be  determined  using  points  1  and  2  as  well  as  5 
and  6.  Unmarshalling  time  can  be  determined  using  points  3  and  4  as  well  as  7  and  8.  Service 
time  can  be  determined  by  using  the  difference  of  the  times  at  points  4  and  5.  If  the  Client  pro¬ 
cess  and  the  Server  process  are  both  on  the  same  machine,  then  points  3  and  4  can  be  used  to 
measure  the  transmission  of  N  +  P  bytes  and  6  and  7  to  measure  the  transmission  of  M  +  Q 
bytes. 

This  system  permits  two  kinds  of  time  measurements.  One  is  a  high  resolution  measure¬ 
ment  in  multiples  of  500  nanoseconds;  the  other  is  in  hundredths  of  a  second.  The  latter  time 
can  be  used  to  measure  wall  clock  time  or  time  spent  in  the  (UNIX)  User’s  address  space  or 
time  spent  in  the  operating  system.  In  order  to  get  the  best  timing  possible,  we  used  the  high 
resolution  measurement  in  the  Client  and  the  Server  in  addition  to  the  points  1-8  per  Figure  6, 
when  that  was  possible.  We  were  not  always  able  to  measure  individual  events,  but  instead  mea¬ 
sured  the  time  required  for  repeated  occurrence  of  the  same  event  and  worked  in  terms  of  aver- 


The  introduction  of  timing  measurement  can  perturb  activity  in  the  Client  address  space 
or  the  Server  address  space.  It  is  important  to  assure  that  the  timing  is  reasonably  stable  and  as 
free  of  noise  due  to  asynchronous  events  as  possible.  Assuming  this  is  done,  one  should  mea¬ 
sure  the  following: 

1.  Typical  cost  of  loceil  procedure  call  in  same  address  space  and  to  system  address 
space  (See  Appendix  C.5) 

2.  Typical  cost  of  loop  overhead  (See  Appendix  C.6) 

3.  Typical  cost  of  measurement  activity,  i.e.  the  cost  of  an  interceptor.  In  our  case,  we 
did  this  by  timing  the  9-point  example  and  the  5-point  example.  We  subtracted  the 
minimum  time  for  each  and  assumed  that  this  time  resulted  from  the  addition  of  the 
interceptor  code  for  four  interceptions. 

4.  Ratio  of  best-case  LPC  to  best-case  RPC,  i.e.,  an  LPC  which  does  no  server  work 
and  an  RPC  which  does  no  server  work.  The  minimal  times  expended  are  best  case, 
because  they  are  the  shortest  times  we  can  obtain. 

5.  Typical  best-case  time  for  marshalling  and  unmarshalling  of  arguments,  in  our 
example  a  string  of  938  bytes.  See  Appendix  C.2. 

6.  Typical  best-case  time  for  transmission  of  arguments,  in  our  case,  938  bytes  of  pay- 
load  +  protocol  and  tagging  data.  See  Appendix  C.2. 

The  reason  we  have  selected  938  bytes  is  that  this  is  the  length  of  the  information  taken  from 
the  data  base  of  the  TCS  of  GCCS.  We  have  selected  this  service  because  it  seems  to  present 
the  most  difficult  challenges  to  a  successful  implementation. 

Assuming  that  these  times  can  be  obtained,  we  will  be  able  to  determine  the  effect  of 
RPC  on  allocation  of  function  in  Clients  and  services  utilizing  information  obtained.  Of  course 
these  values  are  guaranteed  only  for  the  experiments  made  in  the  environments  provided.  By 
making  slight  variations  in  environment,  we  can  determine  how  sensitive  the  results  are  as  a 
function  of  the  environment.  Using  the  results  of  the  experiment  is  more  likely  to  produce  better 
factoring  of  our  applications  into  pieces  which  can  be  distributed  than  using  our  judgment 
alone. 


2.3  CONFOUNDING  FACTORS 


The  set  of  experiments  assumes  that  stable  results  can  be  obtained.  The  following  fac¬ 
tors  can  invalidate  the  results  of  these  experiments  or  invalidate  their  interpretation  in  a  more 
general  setting;  our  experiments  attempted  to  mitigate  these  factors  as  described  in  Section  2.4. 

1 .  Lack  of  high  precision  timer  on  Pentium  90.  A  preferred  Client  for  the  DII  COE  is 
likely  to  be  an  Intel  based  computer  running  the  Microsoft  NT  4.0  operating  system. 
Regrettably,  there  appears  to  be  no  way  to  access  a  high  resolution  clock  on  NT4.0 
clients.  A  60  Hertz  clock  is  available,  but  this  produces  minimum  increments  of 
16.66  ms  which  are  only  useful  for  measurement  of  averages  and  give  us  less  infor¬ 
mation  about  the  distribution  of  times  required  for  satisfaction  of  a  request. 

2.  Lack  of  high  accuracy  coordination  of  times  between  Client  and  Server.  The  high 
resolution  clocks  on  two  different  SPARC  machines  are  not  correlated,  each  mea¬ 
sures  its  own  time,  presumably  from  when  the  system  was  booted.  Because  we  do 
not  have  an  accurate  global  clock,  there  are  a  number  of  measurements  which  we 
cannot  make  with  accuracy.  If  measurements  were  totally  stable,  it  might  be  possi¬ 
ble  to  estimate  an  offset  for  one  of  the  clocks  from  the  other.  Unfortunately,  the  mea¬ 
surements  are  not  stable  enough  for  this  purpose. 

3.  The  work  required  for  reading  a  system  clock  may  distort  measurements.  This  can 
be  due  to  activities  involving  process  exchange  which  may  cause  each  machine’s 
scheduler  to  introduce  latencies  into  the  desired  calculation. 

4.  In  addition  to  3,  the  subroutines  required  for  measuring  time  at  various  points  in  the 
Client-Server-Client  loop  may  distort  measurements  in  a  non-linear  manner. 
Because  of  the  variance  in  iteration  time,  it  is  difficult  to  subtract  out  these  times 
precisely.  However  we  can  gain  an  understanding  of  the  magnitude  of  the  time 
required  to  take  the  measurements  and  verify  that  this  time  is  a  small  percentage  of 
the  total  Client-Server-Client  loop. 

5.  Degree  of  burstiness  and  simultaneous  applications.  The  experiments  involve  run¬ 
ning  a  single  application  at  a  time.  In  the  usual  case,  multiple  applications  will  be 
running  simultaneously.  Use  of  an  ethemet  as  a  communications  medium  produces 
a  latency  vs.  bandwidth  requirement  which  is  very  non-linear  after  50%  of  the  band¬ 
width  is  used.  There  may  be  substantial  dispersion  in  times  for  throughput,  especial¬ 
ly  under  heavy  load.  The  results  obtained  in  this  experiment  are  for  lightly  loaded 
systems  and  will  not  necessarily  apply  under  heavy  loading. 


6.  Security  processing  overhead.  These  experiments  have  ignored  all  effects  of  provid¬ 
ing  security  as  per  Equation  3.  In  cases  where  these  functions  must  be  applied,  the 
developer  must  attempt  to  understand  the  magnitude  of  their  contribution. 

7.  Non-linearities  in  number  of  IP  packets/second  processed.  Typical  work  stations 
reach  a  point  at  which  they  can  no  longer  process  packets.  On  older  work  stations 
such  as  the  Sun  IPX,  this  point  is  around  200  packets  per  second.  On  newer  ones, 
this  limit  is  higher,  but  still  may  be  less  than  1500  packets  per  second  (of  any  size). 

8.  Non-linearities  in  bandwidth  of  IP  packets/second  required  for  transmission.  Each 
medium  and  access  method  has  different  characteristics.  This  set  of  experiments 
assumes  an  ethernet  packet  whose  maximum  size  is  slightly  more  than  1500  bytes 
including  protocol  information.  When  more  than  1500  bytes  are  to  be  transmitted, 
the  original  messages  are  segmented  and  sent  as  multiple  packets,  producing  a  non¬ 
linear  requirement  for  bandwidth  as  a  function  of  message  size.  This  effect  will  be 
even  more  noticeable  with  Internet  Protocol  Version  6  with  large  addresses  enabled, 
since  many  more  bytes  of  overhead  are  introduced.  If  Asynchronous  Transfer  Mode 
(ATM)  transmission  is  used,  similar  non-linearities  may  be  observed.  This  is 
because  the  TCP/IP  and  ATM  error  determination  and  recovery  mechanisms  are  not 
designed  to  work  with  one  another  and  ATM  error  rate  is  permitted  to  be  high,  often 
resulting  in  multiple  re-transmissions  of  ATM  packets  or  error  in  the  IP  transmis¬ 
sion  which  can  require  complete  re-transmission  of  the  TCP/IP  packet. 

9.  LAN/WAN  interfaces  and  queuing.  This  experiment  has  assumed  that  both  Client 
and  Server  are  either  on  the  same  platform  or  that  alternatively  they  are  on  platforms 
which  are  on  the  same  Local  Area  Network  (LAN).  There  is  a  possibility  that  they 
are  on  different  networks  with  a  Wide  Area  Network  (WAN)  connecting  the  LANs. 
In  this  case  attention  must  be  given  to  the  queueing  that  takes  place  at  the  interface 
where  there  is  customarily  a  large  bandwidth  differential,  e.g.,  10  mb/s  and  9600 
bps. 

10.  The  ORB IX IDL  Compiler.  The  interface  definition  language  (DDL)  compiler  which 
IONA  uses  to  produce  C++  implementations  of  ORB-usable  interfaces  is  in  a  state 
of  flux,  improving  at  each  new  version  as  does  their  library  of  supporting  proce- 


dures.  As  noted  by  Schmidt  this  translation  has  a  very  strong  effect  on  the  effi¬ 
ciency  of  marshalling  and  unmarshalling,  particularly  in  the  case  of  large  records. 

1 1 .  Possibility  of  caching.  The  possibility  of  caching  means  that  we  must  ascertain  that 
an  appropriate  amount  of  data  is  transmitted  —  that  the  mechanism  is  not  only 
transmitting  changed  data.  In  a  production  case  we  would  attempt  to  engineer  smart 
proxies  to  take  advantage  of  repetitive,  unchanged  data. 

12.  Lack  of  time  to  try  detailed  optimizations.  Even  though  the  experiments  were  envi¬ 
sioned  as  exhaustive,  there  was  not  enough  time  or  resources  to  try  all  possible  opti¬ 
mizations  which  a  developer  might  perform  in  order  to  meet  required  performance 
goals  or  to  use  proprietary  extensions  of  Orbix  other  than  filters  for  time  measure¬ 
ment  or  smart  proxies. 

2.4  MITIGATION  OF  CONFOUNDING  FACTORS 

The  experiments  were  conducted  in  a  manner  which  attempt  to  mitigate  the  confound¬ 
ing  factors  as  much  as  possible. 

•  Factors  3  and  4.  The  experiments  attempt  to  account  for  extraneous  times  and 
remove  them. 

•  Factors  7  and  8.  The  experiments  used  an  isolated  subnetwork  with  minimum  extra¬ 
neous  traffic  and  linear  duty  cycle;  records  were  made  of  the  network  statistics  in 
an  effort  to  substantiate  operation  in  this  regime. 

•  Factor  9.  A  WAN  was  not  employed;  all  communications  were  performed  on  a  sin¬ 
gle  segment  of  a  LAN.  To  gain  an  understanding  of  the  interprocess  communica¬ 
tion,  an  experiment  using  loopback  TCP/IP  was  used  to  establish  basic  timing  for 
communications  and  for  both  Client  and  Server  processing  times  on  the  same 
SPARC20. 

•  Factor  12.  At  least  one  change  in  returned  value  was  made  at  each  iteration  and  the 
number  of  bytes  and  messages  transmitted  and  received  were  checked  to  ascertain 
that  an  intelligent  caching  scheme  was  not  being  used. 

In  addition  the  following  practices  were  followed; 
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•  Only  the  standard  Basic  Object  Adapter  defined  for  all  implementations  of  CORBA 
Version  2.0  was  employed.  The  interface  definitions  and  Client  and  Server  code  in 
C++  are  provided  so  that  an  interested  party  can  produce  similar  results. 

•  Complete  records  of  each  experiment  were  retained  for  further  examination. 

2.5  EXPERIMENTS  TO  BE  CONDUCTED 

The  goal  of  the  measurements  which  were  made  were  to  try  to  determine  the  parameters 
of  Equation  2  using  a  variety  of  host  platforms  for  the  Client  and  obtaining  the  most  informa¬ 
tion  possible  with  the  fewest  experiments:  one  returning  a  double  precision  value,  another 
returning  a  938  byte  string,  and  a  third  returning  a  VtPlatform  track  (see  glossary)  using  the 
API  of  the  Track  Correlation  Application  Database  Manager. 

2.5.1  Methodology  of  Experiments 

Each  experiment  was  conducted  to: 

1 .  Determine  the  amount  of  time  required  and  number  of  bytes  of  data  transmitted  for 
a  Client/server  interaction.  This  was  accomplished  by  using  a  loop  iterator  to  repeat 
the  RPC  over  and  over  again.  This  showed  us  the  maximum  rate  that  a  Client-Serv¬ 
er-Client  interaction  can  proceed. 

2.  Break  down  the  time  required  per  interaction  into  the  time  required  on  the  Client 
platform,  the  time  required  on  the  Server  platform,  and  the  communications  time 
(as  accurately  as  possible). 

3.  Break  down  the  time  required  on  the  Client  platform  into  the  time  required  for  Cli¬ 
ent  marshalling.  Client  unmarshalling,  and  Client  processing. 

4.  Break  down  the  time  required  on  the  Server  platform  into  the  time  required  for 
Server  unmarshalling.  Server  processing,  and  Server  marshalling. 

5.  If  possible,  decompose  the  communication  time  into  time  spent  on  Client  platform, 
time  spent  on  Server  platform,  and  time  on  the  “wire”  as  a  function  of  the  amount 
of  data  and  kind  of  data. 

Each  experiment  was  performed  in  two  basic  varieties.  In  the  first  we  simply  noted  the 
value  of  the  real  time  clock  when  the  processes  reached  each  measurement  point.  Of  greater 
interest  is  an  experiment  related  to  the  TCS  data  base.  The  TCS  data  base  contains  a  variety  of 
data  records  from  all  sorts  of  data  sensors,  e.g.,  radar,  sonar,  acoustic,  etc.,  which  report  posi¬ 
tions  of  “elements”  at  a  given  instant  of  time.  The  purpose  of  track  correlation  is  to  attempt  to 


fuse  the  data  from  various  sources  such  as  electronic  intelligence,  heat  sensing,  signal  intelli¬ 
gence,  and  human  intelligence,  deconflicting  multiple  instances  of  the  same  track  from  multi¬ 
ple  sensors.  As  a  result,  the  TCS  data  base  contains  12  different  kinds  of  records.  A  simple  kind 
of  display  Client  might  request  the  return  of  track  data  so  that  it  could  present  the  information 
on  a  display.  Instead  of  determining  the  type  of  record  and  requesting  it  specifically,  we  would 
prefer  to  use  a  generic  request  to  return  a  record  which  has  been  appropriately  marshalled  and 
unmarshalled  so  that  it  is  usable  on  both  Intel  and  Sun  Platforms  with  their  different  represen¬ 
tations  of  the  same  data.  The  marshalling  routines  must  determine  which  data  record  format  is 
actually  being  returned  and  marshal  and  unmarshal  it  correctly.  This  problem  is  representative 
of  all  generic  data  base  requests.  Our  experiments  were  expected  to  produce  different  results 
for  the  timing  of  each  kind  of  record  and  they  did.  Two  kinds  of  records  were  actually 
employed,  a  record  of  938  bytes,  and  a  record  containing  a  VtPlatform  record  —  see  Appendix 
A.2.3. 

We  performed  the  above  for  a  Client/Server  interaction  returning  a  very  small  amount 
of  data,  a  string  of  data  approximating  a  track  from  the  TCS,  and  a  structure  of  data  which  is 
one  of  the  12  types  of  tracks  sent  by  the  correlation  Server. 

2.5.2  Equipment  and  Software  Used 

We  used  equipment  available  to  us  at  the  time,  including  two  Sparc20s,  a  Sparc  IPX, 
and  a  Pentium  90.  We  are  fairly  certain  that  the  platforms  had  sufficient  memory  and  processing 
power  to  participate  in  the  experiment.  While  the  Server  platforms  and  Client  platforms  of  the 
DII  COE  used  in  a  production  environment  will  have  substantially  larger  configurations  and 
use  more  capable  networks,  the  results  are  still  representative  and  scale  with  processor  speed 
since  only  a  few  microseconds  are  used  for  transmission  of  the  values  on  network  media.  ( One 
would  have  to  test  to  assure  that  most  of  the  time  is  lost  due  to  processing  and  that  this  time  is 
inversely  proportional  to  the  speed  of  the  processor.). 

The  Sparc20  was  equipped  with  a  75Mhz  clock  and  96  Mb  of  memory.  It  was  always 
used  to  host  the  Server  process  and  as  the  host  for  the  Orbix  2.0. 1  ORB  which  is  CORBA  2.0 
compliant.  This  Sparc20  was  also  used  to  host  the  Client  so  that  loopback  TCP/IP^  ^  could  be 
timed  precisely  and  so  that  all  9  points  could  be  measured  with  the  same  clock,  giving  the  effect 


*  ’  In  loopback  TCP/IP,  the  packets  which  would  have  been  transmitted  over  the  network  are  simply  reflected  by 
the  media  control  and  processed  as  input  without  having  been  transmitted  over  the  network.  The  timings  for 
this  are  slightly  less  than  if  the  data  had  actually  been  sent  over  the  network. 


of  a  global  clock.  It  should  be  noted  that  both  Client  and  Server  were  single  threaded  which 
means  that  the  Client  waits  for  the  Server  to  respond  and  vice  versa. 

A  second  Sparc20  was  equipped  with  a  75  Mhz  clock  and  64  Mb  of  memory.  It  was 
used  exclusively  as  a  second  Client.  Although  its  4  measurement  points  did  not  use  the  same 
clock  as  the  platform  hosting  the  Server,  its  clock  was  as  accurate.  Since  the  cycle  of  Client- 
Server-Client  was  still  employed,  the  two  different  experiments  could  be  compared  for  the  sake 
of  consistency. 

A  Sun  Sparc  IPX  with  24  Mb  of  memory  was  used  as  a  Client  to  verify  the  effects  of  a 
slower  processor  with  similar  data  representation.  The  results  of  these  experiments  are  present¬ 
ed  in  spreadsheet  in  Appendix  B,  Attachment  1  for  completeness,  but  are  not  otherwise  dis¬ 
cussed. 

A  Pentium  90  with  1 6  Mb  of  memory  running  Microsoft  NT4.0  was  used  as  a  Client 
because  it  was  available  equipment.  It  is  not  likely  that  a  Pentium  with  such  low  clock  rate  or 
limited  amount  of  memory  will  be  used  as  deployed  equipment  in  DII  3.2.  More  likely,  a  200 
Mhz  Pentium  would  be  employed;  it  is  about  twice  as  fast.  The  ethemet  controller  on  the  Pen¬ 
tium  90  was  a  3Com  3C509,  an  unoptimized  controller. 

The  ethemet  used  consisted  of  a  central  hub,  a  router,  and  optical  cable  to  the  equip¬ 
ment.  Equipment  on  the  ethemet  was  limited  to  the  2  Sparc20s,  an  IPX,  and  the  Pentium  90.  In 
order  to  use  files  from  the  author’s  machine,  a  file  system  from  that  machine  was  mounted  on 
the  Sparc20  using  the  Network  File  System  of  Sun  Computer.  The  use  of  this  convenience  may 
have  introduced  additional  variance  in  the  results  since  this  use  results  in  the  Sparc20  pinging 
the  host  on  an  infrequent  basis  to  ascertain  whether  it  is  alive.  Based  on  the  results  presented  in 
Appendix  B,  Attachment  1,  this  use  did  not  greatly  add  variance  to  the  results. 

The  operating  system  on  all  the  Sun  machines  was  Sun  Solaris  Version  2.5.  It  is  expect¬ 
ed  that  DII  COE  will  support  this  at  Revision  3. 1 .  (It  supports  2.4  at  DII-COE  Release  3.0).  The 
version  of  Orbix  on  the  Sparc  was  Orbix  2.0.1  which  is  not  a  multi-tasking  version.  A  multi¬ 
tasking  version  would  have  made  more  sense  if  the  ORB  had  been  heavily  loaded  or  if  the  Serv¬ 
er  had  managed  multiple  objects.  The  Sparc  C-H-  Compiler  was  version  4.0.1  (SC3.0.1)  as 
required  by  IONA  for  operation  with  Orbix  Version  2.0. 1 .  The  Sun  version  of  time  and  netstat 
were  used  to  accumulate  centisecond  time  and  network  statistics. 

The  operating  system  on  the  Pentium  90  was  Microsoft  NT  Version  4.0  with  no  patches. 
Orbix  2.0.2  for  NT  was  used  as  the  Client  ORB.  The  compiler/library  suite  used  was  Microsoft 
Visual  C++  Compiler,  Professional  Version  4.2.  Minimal  changes  were  made  in  the  source 


code  of  the  Clients  previously  compiled  and  run  on  the  Sun.  These  changes,  documented  in  the 
Orbix  documentation,  accommodated  the  compiler’s  use  of  macros  to  handle  declarations  of 
nested  classes. 

2.5.3  Variations  to  be  Performed 

Sets  of  trials  were  run  for  each  experiment,  using  four  different  platforms  for  Clients  to 
gain  a  sense  of  robustness. 

First,  each  basic  experiment  was  run  using  nine  time  monitoring  points  —  the  eight  as 
mentioned  above  and  an  explicit  request  in  the  Server  for  high  resolution  time.  These  were  run 
on  the  Sparc20  platform  which  hosted  both  the  Client  and  the  Server  as  well  as  the  pair  of 
Sparc20s.  This  permitted  us  to  gain  a  view  of  the  effect  of  marshalling  and  unmarshalling  ser¬ 
vices  of  greater  and  greater  data  complexity.  While  performing  these  experiments,  we  also  col¬ 
lected  netstat  statistics  and  Unix  centisecond  timing  as  described  previously  in  Section  2.2. 
This  gave  us  confidence  in  the  facts  that 

1.  Our  network  was  lightly  loaded. 

2.  The  number  of  bytes  and  the  number  of  messages  transmitted  were  as  expected. 

3.  Our  high  resolution  timing  measurements  were  consistent  with  the  low  resolution 
measurements  made  over  the  entire  experiment. 

Second,  we  disabled  the  four  collection  points  in  the  Client,  and  ran  each  experiment 
again  with  Client  and  Server  on  the  same  platform.  This  left  five  collection  points  in  the  Server. 
We  did  this  because  we  ran  this  experiment  across  the  four  different  Client  options  and  we 
knew  that  the  Pentium  90  does  not  have  a  high  resolution  clock  equivalent.  Third  we  ran  the 
Client  compiled  for  the  Sparc20  on  the  second  Sparc20  to  see  the  effect  of  using  loopback  ver¬ 
sus  using  the  network.  Fourth,  that  same  Client  was  run  on  the  IPX  to  see  the  effect  of  perfor¬ 
mance  of  a  slower  Client.  Finally,  the  source  of  the  Client  was  transported  to  the  Pentium, 
modified  as  required  for  Microsoft  C++,  and  run  as  a  Client  on  the  Pentium  90  under  Microsoft 
NT4.0.  In  this  last  case  the  Microsoft  NT  version  of  netstat  was  used  to  collect  network  statis¬ 
tics.  This  set  of  results  in  profile  showed  consistency  across  the  Spares  and  showed  diversity  in 
the  Sparc  vs.  Pentium  with  respect  to  marshalling,  transmission  times,  number  of  messages, 
etc. 

The  first  experiment  involved  sending  an  integer  value  from  Client  to  Server.  See  the 
code  in  Appendix  C.  1 .  The  Server  returns  a  double  scalar  which  is  the  high  resolution  time. 
This  experiment  provides  basic  performance  loop  time  against  which  all  other  results  can  be 


compared.  It  must  be  performed  enough  times  so  that  the  experimenter  can  have  relative  con¬ 
fidence  in  the  results  —  in  all  cases  10,000  times.  The  number  10,000  was  chosen  because  this 
number  of  observations  could  be  collected  in  random  access  memory  for  each  of  the  collection 
points  and  sent  to  disk  after  the  test  was  complete,  minimizing  the  effect  of  the  printing  on  the 
experiment.  Capturing  each  value  allowed  display  of  the  distribution  of  round-trip  timing  val¬ 
ues  as  a  histogram.  Its  results  help  us  to  understand  the  ratio  of  overheads  for  LPC  versus  RPC 
in  the  simplest  case. 

By  comparing  the  nine  point  experiment  running  on  the  pair  of  Sparc20s  to  the  five 
point  experiment  running  on  the  Sparc20s  we  may  determine  how  much  time  is  used  in  four 
calls  to  the  time  monitoring  routines  using  the  Orbix  framework. 

The  second  experiment  requires  sending  an  integer  value  from  Client  to  Server.  See  the 
code  in  Appendix  C.2.  The  Server  returns  a  double  scalar  which  is  high  resolution  time  and  a 
938  byte  string  to  determine  marshalling/unmarshalling  time  and  communications  time  for 
sending  strings.  This  experiment  helps  us  to  understand  the  overhead  of  using  a  fixed  length 
string  of  bytes  as  the  answer  to  a  request.  The  time  for  this  should  be  lower  than  for  returning 
any  structured  value  of  the  same  length. 

The  third  experiment  requires  sending  an  integer  value  from  Client  to  Server.  The  Serv¬ 
er  returns  a  double  scalar  which  is  high  resolution  time  and  a  938  byte  structure  to  determine 
marshalling/unmarshalling  time  and  communications  time  for  sending  structures.  This  struc¬ 
ture  is  our  representation  of  the  VtPlatform  Track,  a  938  byte  complex  structure  described  in 
Appendix  C.3.  This  experiment  tells  us  the  overhead  of  returning  a  typical  structured  value 
from  the  data  base. 

Additional  experiments  were  also  conducted  to  determine  the  time  for: 

1.  A  do  loop  containing  no  server  work.  See  Appendix  C.6. 

2.  A  loop  of  subroutine  calls  to  a  null  routine  returning  a  void  result.  See  Appendix 
C.5. 

3.  A  loop  of  subroutine  calls  to  the  high  resolution  clock.  See  Appendix  C.4. 

2.6  DATA  WHICH  WAS  CAPTURED 

In  the  three  experiments,  the  following  data  was  captured  for  each  Client/Server  pair: 

1 .  High  Resolution  time  for  each  Call-Service-Retum-Process  Loop  (10,000  values). 

2.  Real,  User,  and  System  Time  (Unix  System). 


3.  High-resolution  times  at  each  collection  point. 

4.  Network  statistics:  before  and  after  Client  and  Server  runs. 

In  the  additional  experiments,  the  following  data  was  captured: 

1 .  High-resolution  time  to  perform  1  billion  null  iterations  of  a  for-loop. 

2.  High-resolution  time  to  perform  1  billion  subroutine  calls  returning  a  double  scalar 
type. 

37“  High-resolution  time  to  perform  1  billion  subroutine  calls  to  the  high-resolution 
clock. 

The  following  information  was  derived  from  the  values  collected  (See  Attachment!  in 
Appendix  B): 

1.  High-resolution  times  for:  Server  Proxy  Pre  &  Post  Marshal,  Client  Proxy  Pre  & 
Post  Unmarshal,  Client  Proxy  Pre  &  Post  Marshal,  Server  Proxy  Pre  &  Post  Unmar¬ 
shal. 

2.  Roundtrip  average  times,  maximum  times,  minimum  times,  standard  deviation,  his¬ 
togram. 

3.  Times  for:  Server  Proxy  Marshal,  Client->Server  or  Client  +Transport  (When  dif¬ 
ferent  clocks  are  used).  Client  Proxy  Unmarshal,  Server  Execution,  Client  Proxy 
Marshal,  Server->Client  or  Server  -«-Transport  (when  different  clocks  are  used). 
Server  Proxy  Unmarshal,  and  Client  Execution. 

4.  Input  Packets,  Bytes,  ipInDelivers,  “msgs”  (transmitted):  to  see  the  effect  of  dynam¬ 
ic  tagging  and  alignment  of  byte  strings  and  structures,  and  to  see  how  many  mes¬ 
sages  are  transmitted,  and  to  verify  that  the  network  is  relatively  inactive. 


CHAPTER  3.  RESULTS  OF  MEASUREMENT 


A  spreadsheet  detailing  results  in  capsule  form  is  included  in  Appendix  B  as  Attach¬ 
ment  1 .  This  chapter  will  summarize  the  extra  experiments  and  comment  on  each  of  the  three 
main  experiments  in  sections  below. 

3.1  EXTRA  EXPERIMENTS 

The  extra  experiments  are  required  to  help  us  deal  with  the  confounding  factors  3  and 
4.  They  also  provide  a  good  idea  of  the  capability  of  the  platform. 

The  execution  of  an  add  instruction  on  a  Sparc  architecture  takes  about  one  instruction 
cycle  and  a  load  instruction  takes  between  3  and  6  cycles.  A  cycle  on  a  75  Mhz  Sparc20  is  1/ 
75,000,000  or  13  nanoseconds  (ns). 

One  billion  executions  of  a  for-loop  with  no  executable  part  required  an  average  of  80.6 
ns  or  about  6  cycles. 

One  billion  calls  in  a  for-loop  to  a  time  routine  with  a  null  body  yielded  an  average  of 
1237.8  ns  per  loop  iteration  or  1 157.2  ns.  per  subroutine  call  or  about  89  cycles. 

One  billion  calls  in  a  loop  to  the  high  resolution  clock  (presumably  through  the  operat¬ 
ing  system)  yielded  an  average  of  1551.2  ns  per  loop  iteration  or  1470.6  ns  per  call.  Note  that 
this  was  about  3 13  ns  more  than  the  null  subroutine  or  an  extra  24  cycles. 

3.2  DOUBLE  PRECISION  TIME  RETURNED  (MAIN  EXPERIMENT  1) 

The  following  is  the  interface  specification  for  the  first  experiment. 

//  a  simple  IDL  interface:  time.  Objects  of  this  interface  provide  an 
II  operation  'hr_time'  which  takes  an  unsigned  long  value  which  may  signal 
//  termination  of  the  Server  and  returns  the  double  real-time  in  nanoseconds 
//  (if  vin  does  not  signal  termination  of  the  Server). 

interface  time  {double  hr_time  (in  unsigned  long  vin) ; } ; 

Only  the  results  obtained  from  the  five  point  experiments  are  discussed  below.  They  are  quite 
similar  to  the  results  of  the  nine  point  experiments. 


3.2.1  Client  and  Server  on  Same  Platform 
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Figure  7.  Client  and  Server  on  Same  Platform 


A  histogram  of  the  times  required  for  the  complete  execution  of  the  iteration  of  a  call 
from  the  Client  to  the  Server  and  return  was  obtained  for  the  10,000  invocations  of  the  time 
interface.  The  histogram  portrays  the  variability  of  the  time  for  an  iteration  and  gives  an  idea 
of  the  distribution  of  the  values  (for  this  experiment).  In  all  cases  the  “tail”  of  the  distribution 
is  very  long.  A  sense  of  how  long  can  be  obtained  from  the  ratio  of  minimum  time  to  maximum 
time  for  an  iteration  or  by  alternatively  noting  that  the  standard  deviation  is  typically  on  the 
order  of  1/4  the  mean. 

A  complete  invocation  of  the  loop  is  denoted  a  roundtrip.  The  shortest^ ^  roundtrip  on 
same  platform  for  the  interface  above  is  ~  1.6 18  ms  or  1043  times  the  per-loop  high-resolution¬ 
time  local  procedure  call  time.  The  longest  roundtrip  in  the  same  trial  was  -25.3  ms  or  16,318 
times  this  basic  time.  The  average  time  was  1.692  ms  and  the  standard  deviation  was  0.369  ms 
about  22%  of  the  mean  value.  The  time  from  Client  to  Server  was  0.939  ms  and  from  Server  to 
Client  was  0.364  ms,  yielding  a  total  of  1.303  ms  for  transmission. 

3.2.2  Client  and  Server  on  Different  SPARC20s 

A  histogram  of  the  times  required  for  the  complete  execution  of  the  iteration  of  a  call 
from  the  Client  to  the  Server  and  return  was  obtained  for  the  10,000  invocations  of  the  inter¬ 
face.  The  minimum  round-trip  time  was  1 .589  ms,  less  than  the  minimum  time  for  the  co-host- 
ed  Client  and  Server.  The  maximum  time  for  a  round  trip  was  134.7  ms,  exhibiting  much  larger 
dispersion.  The  average  time  for  round  trip  was  1.649  ms  and  the  standard  deviation  was  1.437 
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‘  For  this  variety  of  this  experiment;  minimum  times  are  subject  to  the  variable  time  in  send.  A  repetition  of  the 
experiment  might  discover  a  smaller  or  a  larger  minimum  time. 


ms.  Since  the  long  event  biased  the  standard  deviation  so  much,  this  standard  deviation  is  not 
unusual. 
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Figure  8.  Client  and  Server  on  Different  Sparc20s 


In  the  case  where  the  real  time  clock  was  noted  at  all  nine  points,  the  average  time 
required  for  the  Server  +  Transport  was  1 .44  ms  which  could  be  determined  by  the  timings  on 
the  Client;  the  average  time  required  for  the  Client  +  Transport  was  1 .60  ms  which  could  be 
determined  by  the  timings  on  the  Server.  In  this  case  the  total  roundtrip  time  was  an  average 
1.721  ms.  Thus  the  Client  can  be  inferred  to  have  taken  0.281  ms  and  the  Server  0.121  ms,  so 
Transport  must  have  taken  approximately  1.319  ms  for  the  sum  of  the  transfer  from  Client  to 
Server  and  that  from  the  Server  to  the  Client.  Unix  time  revealed  that  the  Server  was  busy  1.6 
ms  per  invocation,  but  this  time  included  amortization  of  the  50,000  line  printout  at  the  end  of 
the  experiment.  A  more  detailed  experiment  might  have  measured  this  timing,  with  the  printout 
function  nulled  out. 

3.2.3  Server  on  SPARC20  and  Client  on  Pentium  90 


Display  Client 

Pentium  90  ^ 

1 

Correlation  Server 


Communications 


Sparc20 


Figure  9.  Client  and  Server  on  Different  Platforms 


A  histogram  of  the  times  required  for  the  complete  execution  of  the  iteration  of  a  call 
from  the  Client  to  the  Server  and  return  was  obtained  for  the  10,000  invocations  of  the  inter¬ 
face.  The  minimum  roundtrip  was  3.63  ms,  about  2.2  times  that  of  a  Sparc20.  (This  is  likely 
due  to  the  lower  performance  of  the  Pentium  90,  but  without  a  high  resolution  clock,  we  cannot 
categorize  the  reduction  in  performance  precisely.)  The  maximum  roundtrip,  43.56  ms,  was 
substantially  better  than  the  pair  of  Sparc20s.  The  average  roundtrip  was  4.06  ms,  about  2.46 
times  that  of  a  Sparc20.  The  standard  deviation  was  0.554  ms.  Client  +  Transport  took  an  aver¬ 
age  time  3.93  ms,  leaving  the  Server  at  0. 13  ms,  very  close  to  what  we  might  expect.  The  Server 
was  busy  about  1.557  ms  including  writing  the  output  file,  which  is  close  to  the  time  required 
when  two  SPARC20s  interworked. 

3.3  938  BYTE  STRING  RETURNED  (MAIN  EXPERIMENT  2) 

The  second  experiment  involved  the  return  of  a  string  of  938  bytes  from  the  Server,  a 
token  track.  Conveyance  of  an  actual  track  as  a  stream  of  bytes  could  be  expected  to  work  cor¬ 
rectly  only  if  the  Client  and  the  Server  were  on  the  same  type  of  machine  since  an  actual  track 
is  a  combination  of  integers,  floating  point  numbers,  structures,  and  strings.  Use  of  a  string  to 
represent  a  structure  of  elements  might  not  convey  a  track  record  correctly,  if  one  machine  was 
a  Sparc  with  a  64  bit  Operating  System  (OS)  and  the  other  had  a  32  bit  OS,  because  of  align¬ 
ment  and  representation  differences.  It  would  certainly  not  work  correctly  if  the  actual  data  rep¬ 
resented  a  VtPlatform  track' ^  and  the  Client  was  a  Pentium  machine  since  Sun  and  Pentium 
use  different  alignments  and  byte  orders.  If  IDL  is  used  for  the  actual  track,  the  code  generated 
by  the  IDL  compiler  correctly  deals  with  alignment  and  data  representation  issues. 

typedef  string<938>  VtTrack; 

interface  Trax  { 

void  print  (in  long  signal); 

void  get  (in  long  index,  out  VtTrack  track,  out  double  time) ; 

}; 

3.3.1  Client  and  Server  on  Same  Platform 

The  minimum  roundtrip  time  was  1 .77  ms  and  the  maximum  was  19.4  ms.  This  is  about 
the  same  amount  of  dispersion  as  encountered  in  the  previous  experiment.  The  average 
roundtrip  time  was  1.86  ms  and  the  standard  deviation  was  0.321  ms.  From  Client  to  Server  (in 
Attachment  1)  took  0.979  ms  and  from  Server  to  Client  was  0.384  ms,  resulting  in  a  total  com¬ 
munication  time  of  1.363  ms  or  0.03  ms  more  than  the  transmission  time  for  a  transmission  of 
8  bytes. 

See  Appendix  A. 3. 5,  typedef  for  A27  —  a  VtPlatform  track. 


The  time  for  the  Client  Proxy  to  unmarshal  its  arguments  was  0.017  ms  and  for  the  Cli¬ 
ent  Proxy  to  marshal  the  results  was  0.05365  ms.  This  does  not  represent  a  serious  difficulty 
when  compared  to  the  communication  time  above. 

3.3.2  Client  and  Server  on  Different  SPARC20s 

When  two  Sparc20s  are  used,  the  minimum  roundtrip  time  increased  to  2.629  ms  and 
the  maximum  to  23.83  ms.  The  average  also  increased  to  2.684  ms  and  the  standard  deviation 
increased  to  0.405  ms.  This  is  likely  do  to  the  difficulty  of  coordinating  the  two  operating  sys¬ 
tems. 

The  time  for  Client  +  Transport  was  2.5  ms  and  for  Server  +  Transport:  2.391  ms.  The 
latter  was  measured  with  a  nine-point  experiment. 

The  time  for  the  Client  Proxy  to  unmarshal  arguments  was  0.015  ms  and  for  the  Client 
Proxy  to  marshal  was  0.053  ms  (3.6  •  basic),  which  was  as  expected. 

3.3.3  Server  on  SPARC20  and  Client  on  Pentium  90 

When  the  Pentium  90  was  used  as  the  Client,  the  minimum  roundtrip  time  increased 
again  to  4.7  ms  as  did  the  maximum  to  48.59  ms.  The  average  was  5.1 1  ms  and  the  standard 
deviation  was  0.618  ms. 

The  Client  +  Transport  time  was  4.917  ms  average.  This  is  almost  twice  the  time  for  the 
two  Sparc20s. 

Again  the  Client  Proxy  unmarshal  time  was  about  the  same:  0.018  ms  as  was  the  Client 
Proxy  marshal  time  of  0.060  ms. 

3.4  VTPLATFORM  TRACK  RETURNED  (MAIN  EXPERIMENT  3) 

The  third  experiment  was  closest  to  reality:  the  contents  of  a  VtPlatform  track  was 
returned  from  the  Server  in  addition  to  the  high  resolution  time.  The  expected  variation  in  this 
instance  is  the  marshalling,  unmarshalling,  and  transmission  times  because  the  data  is  highly 
structured. 

interface  Trax  { 

void  print  (in  long  signal); 

void  get  (in  long  index,  out  VtPlatf ormTrack  track, 
out  double  time) ; 

}; 
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3.4.1  Client  and  Server  on  Same  Platform 

When  the  Client  and  Server  processes  are  hosted  on  the  same  platform,  the  minimum 
roundtrip  time  increased  about  50%  over  the  string  results  to  2.50  ms,  whereas  the  maximum 
time  remains  about  the  same  at  19.6  ms.  The  average  was  2.57  ms;  the  standard  Deviation  was 
0.322  ms,  about  the  same  as  before. 

The  time  for  transmission  from  Client  to  Server  was  0.994  ms;  from  Server  to  Client  it 
was  0.415  ms,  an  increase  of  14%. 

The  Client  Proxy  unmarshal  time  increased  sharply  to  0.339  ms  (20  times  the  case  of 
the  string)  and  the  Client  Proxy  marshal  time  increased  to  0.248  ms  (almost  5  times  the  time 
for  the  string).  It  was  not  clear  why  the  unmarshalling  time  increased  greatly.  A  hypothesis  is 
that  the  unmarshalling  stage  allocates  storage  for  the  returned  result.  In  the  case  of  the  VtPIat- 
form  track,  this  is  a  very  expensive  operation  because  so  many  parts  of  the  result  must  be  allo¬ 
cated. 

The  total  time  used  by  the  Server  process  is  2.22  ms  including  writing  all  Server  timings 
to  the  file. 

3.4.2  Client  and  Server  on  Different  SPARC20s 

In  the  case  when  two  different  Sparc20s  are  used,  the  minimum  roundtrip  time  is  3.6 
ms  and  the  maximum  time  is  19.03  ms.  The  average  time  was  3.67  ms  and  the  standard  devia¬ 
tion  was  0.405  ms. 

The  Client  +  Transport  time  was  2.979  ms;  the  Server  -f-  Transport  time  was  3.187  ms 
(measured  with  9  measuring  points). 

Client  Proxy  unmarshal  time  required  0.334  ms  (about  22  times  the  time  required  for 
the  string);  Client  Proxy  marshal  time  required  0.273  ms  (about  5  times  the  time  for  the  string). 

3.4.3  Server  on  SPARC20  and  Client  on  Pentium  90 

When  the  Client  was  transported  to  the  Pentium,  the  minimum  roundtrip  time  was  6.20 
ms,  about  1/3  higher  than  with  the  string.  The  maximum  roundtrip  time  was  45.21  ms.  The 
average  was  6.65  ms  and  the  standard  deviation  was  0.585  ms.  The  distribution  of  values  is  very 
high  in  the  general  region  of  the  mean  and  drops  off  quite  sharply;  however,  a  number  of  the 
10,000  values  are  quite  disperse  from  the  mean,  yielding  the  large  standard  deviation.  The  dis¬ 
tribution  of  results  looks  more  like  a  Raleigh  distribution  than  a  Gaussian  distribution.  See  the 
graph  of  distribution.  Appendix  B,  Attachment  2. 
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The  time  for  Client  +  Transport  was  5.851  ms. 

The  time  for  Client  Proxy  unmarshal  was  0.419  ms  and  for  Client  Proxy  Marshal  was 
0.273  ms. 

3.5  ADDITIONAL  INFORMATION 

Additional  information  can  be  found  in  the  detailed  spreadsheet  of  Appendix  B,  Attach¬ 


ment  1. 


CHAPTER  4.  SUMMARY  OF  OBSERVATIONS 


The  set  of  experiments  have  led  to  some  summary  observations.  In  the  following  we 
will  simplify  those  results  in  order  to  aid  in  “back-of-the-envelope”  analyses  by  developers. 
{Caution:  your  results  may  vary  widely  from  ours  because  of  equipment,  software,  applica¬ 
tions,  or  use.)  On  a  Sparc20,  a  local  procedure  call  to  the  timer  with  a  minimal  returned  result 
costs  about  1,5  microseconds  (|xs).  A  minimal  Orbix  RPC  to  the  timer  with  a  minimal  returned 
result  costs  about  1.5  milliseconds  (after  removing  timing  and  looping)  or  1000  times  longer^'^. 
Communications  costs  about  1.3  ms  of  that  RPC  time.  In  order  to  have  50%  efficiency  using 
RPC,  the  work  done  by  the  Server  would  have  to  be  >  1000  LPCs  or  1 .5  ms;  for  a  90%  efficien¬ 
cy,  more  than  9000  LPCs  or  13.5  ms  would  be  required.  Thus  for  high  efficiency  the  work  per¬ 
formed  on  the  Server  should  be  very  much  greater  than  1  ms. 

Substantial  time  is  used  by  communications:  1.3  ms  with  very  small  messages  in  each 
direction  on  the  Sparc20  in  loopback  mode.  More  time  is  used  if  a  physical  network  is  used.  If 
a  9600  baud  network  were  used,  and  the  associated  186  bytes  of  protocol  and  message  were 
transmitted  in  the  case  of  the  high  resolution  timing  call,  assuming  10  bits  per  character,  an 
additional  time  of  nearly  200  ms  would  be  required  for  transmission  time^^.  Use  of  an  ethemet 
on  the  other  hand  would  only  require  an  additional  149  ps  for  transmission. 

Substantial  additional  time  is  required  for  handling  heterogeneity,  e.g.,  using  Orbix 
2.0.1  for  marshaling  strings  (0.13  ms)  or  structures  (0.95  ms).  Time  required  is  a  strong  func¬ 
tion  of  the  complexity  of  the  returned  quantity,  due  to  allocation  and  copying.  It  is  likely  that 
different  DDL  compilers  will  handle  marshalling  and  unmarshalling  differently;  hand-opti¬ 
mized  code  for  marshalling  and  unmarshalling  may  be  required  in  order  to  achieve  usable 
results,  particularly  in  the  case  of  very  long  or  very  complex  arguments. 

Even  a  Sparc20  cannot  handle  very  many  object  requests  per  second.  Suppose  we 
assume  that  half  of  the  time  of  Client-to-Server  and  Server-to-Client  is  used  by  the  Server.  This 


Even  if  a  different  RPC  mechanism  were  found  which  offered  little  overhead  in  its  RPC,  it  is  unlikely  to  be 
faster  than  250  times  a  LPC.  See  Attachment  2  in  Appendix  B. 

There  might  be  an  additional  latency  proportional  to  the  distance  travelled. 
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would  yield  a  total  of  0.65  ms  in  the  case  of  returning  high  precision  time.  Client  Proxy  unmar¬ 
shal  requires  0.02  ms.  The  Server  uses  0.08  ms.  Client  Proxy  marshalling  uses  another  0.03  ms. 
This  totals  0.78  ms.  Thus  an  upper  bound  on  the  number  of  requests  that  the  Sparc20  could  han¬ 
dle  is  approximately  1280  per  second  without  performing  any  other  activity.  The  actual  maxi¬ 
mum  will  be  substantially  lower. 

Returning  a  938  byte  payload,  we  know  that  the  Server  +  Transport  requires  2.391  ms 
(from  measurements  on  the  Client  side  of  two  Sparc20  platforms).  Subtracting  out  the  Server 
times  by  using  measurements  on  the  Server,  of  0.689  ms,  we  get  1.7  ms.  If  we  attribute  half  to 
the  Client  Platform  and  half  to  the  Server  Platform,  we  find  the  transmission  time  attributable 
to  the  Server  is  0.85  ms.  Combined  with  the  Server  usage,  this  results  in  1.54  ms.  Thus  only 
649  requests  per  second  could  be  serviced  by  a  single  Sparc20.  Further,  no  additional  opera¬ 
tions  could  be  handled  by  the  Sparc20. 

Use  of  the  information  acquired 

Suppose  we  wished  to  divide  the  GCCS  Track  Correlation  Application  into  a  display 
client  and  a  correlation  server  which  accesses  a  track  database  using  the  current  track  database 
API.  Assume  that  track  updates  occur  at  a  rate  of  1000  per  second,  that  tracks  are  stored  in  a 
memory  cache,  and  that  information  is  disseminated  using  RPC  based  on  the  API  above  using 
a  single  request  to  return  a  single  record. 

Based  on  the  current  experiments  are  the  following  tentative  conclusions:  The  simple 
division  of  the  track  correlation  application  into  display  client  and  track  correlation  database 
with  our  simple  use  of  request-reply  semantics*^  could  not  meet  the  requirement  of  1000  que¬ 
ries  per  second  on  the  measured  equipment  with  the  version  of  software  used.  It  remains  to  be 
seen  whether  a  different  processor  or  a  different  strategy  such  as  sequential  transmission  of 
multiple  tracks  would  better  utilize  the  processor  so  that  the  server  work  could  be  done  in  the 
time  required.  Design  strategies  must  also  be  reconsidered  if  a  higher  performance  processor, 
a  different  or  improved  ORB/IDL/Library  combination,  or  a  better  implementation  of  TCP/IP 
is  used. 


The  semantics  of  local  and  remote  procedure  call. 

In  a  push  mode  where  the  service  sends  all  relevant  data  at  once  instead  of  one  track  at  a  time. 


CHAPTERS.  RECOMMENDATIONS  FOR  DESIGN 


Based  upon  our  experiments,  we  recommend  that  designers  or  developers  should  care¬ 
fully  consider  the  timing  properties  of  the  delivery  platform(s)  and  of  the  software  during  the 
design  of  any  distributed  application: 

•  Developers  should  create  a  simple  prototype  from  which  they  will  gain  the  informa¬ 
tion  required  for  their  design.  For  the  targeted  client  and  server  platform,  designers 
should  employ  the  hardware  and  software  which  will  support  the  delivered  applica¬ 
tion.  Designers  should  determine  the  time  to  marshal’®  and  unmarshal  the  data 
structures  to  be  used.  In  addition  they  should  measure  the  amount  of  communica¬ 
tions  time  taken  by  each  different  kind  of  remote  procedure  call  and  the  amount  of 
time  required  to  service  each  request.  This  should  lead  to  a  mathematical  model  of 
the  amount  of  resources  required  to  perform  each  kind  of  request.  These  times  can 
also  be  used  in  simulations  of  the  applications  to  be  designed. 

•  Designers  or  developers  should  give  special  attention  to  the  following  factors: 

-  Carefully  consider  the  amount  of  computation  to  be  done  on  the  server  for  each 
RPC.  Too  little  computation  on  the  server  reduces  the  overall  efficiency  of 
computation  because  of  the  communications  overhead.  Perhaps,  move  ineffi¬ 
cient  computations  to  clients. 

-  Carefully  consider  the  type  of  argument(s)  to  be  passed  to  the  server  or 
returned  to  the  client.  Try  to  make  the  argument  as  simple  and  as  aligned  as 
possible.  Attempt  to  find  an  implementation  of  IDL  that  can  perform  marshal¬ 
ling,  unmarshalling,  and  service  in  parallel,  using  threads.  This  is  particularly 
valuable  if  the  service  performs  I/O  operations. 

-  If  the  task  can  be  parallelized,  use  multiple  servers  and  distribute  the  computa¬ 
tion  (servers)  on  multiple  platforms.  Also  try  to  hide  communications  latencies 
by  using  multi-threaded  servers  to  handle  multiple  requests  in  a  pipelined  fash- 

1  Q 

See  the  body  of  the  paper  or  glossary  for  definition  of  technical  terms  such  as  marshalling  and  unmarshalling. 


ion.  Find  the  sum  of  times  on  the  paths  which  must  be  performed  serially.  This 
is  the  optimum  time  which  can  be  achieved  [one  of  Amdahl’s  laws].  You  may 
think  that  using  many  machines  executing  a  task  in  parallel  pieces  will  reduce 
the  total  computation  time.  But  you  must  account  for  the  overhead  introduced 
by  the  communication.  Verify  that  the  time  for  using  multiple  servers  is  shorter 
than  running  the  calculation  on  a  single  machine  using  LPC. 

Carefully  consider  the  factors  which  could  render  your  experimental  results 
invalid  such  as  communications  to  other  servers  on  the  same  host.  Try  to  deter¬ 
mine  if  they  will  contribute  to  your  client-server  workload.  Especially  consider 
the  number  of  requests  per  second  to  database  servers  and  the  amount  of  I/O 
operations  these  servers  are  expected  to  perform. 

-  Carefully  consider  the  confounding  factors.  Try  to  characterize  them  in  order 
to  determine  if  they  will  contribute  to  your  client/server  workload.  If  they  will, 
identify  mitigation  strategies.  Especially  consider  the  number  of  requests  per 
second  to  database  servers  and  the  amount  of  I/O  these  servers  are  expected  to 
do. 

As  has  been  suggested  in  the  illustrative  examples,  results  vary  depending  on  many  fac¬ 
tors.  What  is  important  is  to  experiment  and  model  during  design  to  determine  what  factors  are 
most  significant  and  what  can  be  done  to  improve  performance. 

5.1  BUILD  A  PROTOTYPE  TESTING  CAPACITY 

In  the  same  way  that  this  task  developed  a  prototype  which  could  perform  a  check  on 
the  capacity  of  the  system,  the  developer  should  build  and  measure  a  “simple  prototype”  which 
will  gain  the  information  required  for  his/her  design.  For  the  Client  and  Server  platform 
involved,  the  designers  should  employ  the  hardware  and  software  which  will  support  the  deliv¬ 
ered  application  in  their  prototype. 

As  mentioned  in  bullet  1  of  section  5.1  above,  for  each  Client  request,  determine  the 
following  (based  on  Figure  10): 

a.  Time  for  Server  Proxy  Marshal,  Tl=T2-'ti 

b.  Time  for  Transmission  of  Client  packets  and  number  of  packets  and  bytes  transmit¬ 
ted  by  Server  Proxy,  T2=TyX2 

c.  Time  for  Client  Proxy  Unmarshal,  T3=T4-T3 


d.  Time  for  Service  Action,  T4=T5-X4 

e.  Time  for  Client  Proxy  Marshal,  T5=i5-T5 

f.  Time  for  transmission  of  the  Server  packets  and  number  of  packets  and  bytes  trans¬ 
mitted  by  the  Client  Proxy,  T6=T7-X6 

g.  Time  for  Server  Proxy  Unmarshal,  T7=Xg-X7 

h.  Time  for  Client  Action,  T8=Xj-Xg  (when  looping) 


I - 1  I - - - 1 


Figure  10.  Experimental  Monitoring  Points 


Actual  values  for  the  “T”s  for  our  experiments  are  calculated  in  Attachment  1 .  Your  values 
will  likely  differ  from  these  values,  depending  on  your  hardware,  network,  and  software. 
Inserting  the  timing  probes  can  be  difficult  on  a  PC  running  Microsoft  NT  or  using  a  different 
ORB^^.  If  the  platform  is  the  problem,  use  the  same  ORB  on  a  platform  supporting  a  high  res¬ 
olution  clock  and  attempt  to  scale  the  result  to  account  for  platform  speed  and  data  transport. 
Most  ORBs  support  interceptors;  if  yours  does  not,  you  may  have  to  try  to  instrument  the 
operating  system  in  order  to  get  the  information  you  wish  or  use  binary  debugging  tools  to 
insert  a  call  to  the  measurement  apparatus. 

By  determining  how  many  bytes  B 1  and  packets,  by  using  netstat  or  equivalent,  are 
transmitted  by  the  Server  Proxy  at  10,  estimate  how  many  packets  are  required  to  convey  the 

For  example,  PowerBroker  by  Expersoft  only  provides  a  per-process  interceptor  at  points  1 ,3,5,  and  7,  making 
the  profiling  performed  in  Orbix  extremely  difficult  to  perform. 


Client’s  request  to  the  Server  (See  attachment  1  for  our  values).  By  determining  how  many 
bytes  B2  are  transmitted  by  the  Client  Proxy,  at  1 1,  estimate  how  many  packets  are  required  to 
convey  the  Server’s  reply  to  the  Client.  Determine  how  much  real-time  is  used  by  the  transmis¬ 
sion  of  the  packets  assuming  optimum  transmission  (Bl+B2)/(BandWidth)  (50%  of  bandwidth 
on  WAN  and  LAN-ethemet;  80%  of  bandwidth  on  FDDI  or  token  ring  can  be  used).  Determine 
how  much  real-time  is  used  by  the  transmission  of  the  packets,  (T2+T6).  Sum  the  real-time 
required  of  the  communications  device  by  the  Client  request  and  the  Server  response  and  deter¬ 
mine  how  many  request/response  pairs  could  be  sent  per  second.  Sum  the  number  of  packets 
required  for  each  request/response  pair  and  divide  this  into  the  maximum  number  of  packets 
that  the  Client/Server  can  handle  (whichever  is  smaller).  The  number  of  actual  request  response 
pairs  determined  for  communication  is  the  lesser  of  that  determined  by  the  packet  method  or 
the  bandwidth  method. 

Attempt  to  estimate  the  time  which  is  required  by  the  Server  for  handling  communica¬ 
tion  to  and  from  the  Server:  (T2+T6)/2.  Add  this  to  T3,  T4,  and  T5  to  determine  the  amount  of 
the  time  used  by  the  Server’s  platform  in  order  to  perform  the  request.  Estimate  the  platform’s 
capacity  by  determining  the  maximum  number  of  requests  that  the  Server  could  handle  if  it 
only  performed  this  request  repeatedly.^® 

Attempt  to  estimate  the  time  which  is  required  by  the  Client  for  handling  communica¬ 
tion  to  and  from  the  Client.  Add  this  to  times  Tl,  T6,  and  T7  to  determine  the  amount  of  the 
time  used  by  the  Client’s  platform  in  order  to  send  the  request  and  process  its  results.  Estimate 
the  platform’s  capacity  by  determining  how  many  requests  the  platform  can  issue  per  second  if 
it  performs  no  client  work  on  the  results  it  obtains. 

The  maximum  number  of  requests  per  second  is  the  least  of  the  number  obtained  by  the 
communications  method,  the  Server  method,  and  the  Client  method  as  described  above.  This 
number  is  likely  an  optimistic  number  because  it  does  not  take  into  account  the  “confounding 
factors”  in  Section  2.3. 

After  having  determined  these  numbers  for  each  kind  of  request  to  be  issued,  estimate 
the  number  of  each  kind  of  request  to  be  issued  per  second.  Using  the  Server,  Client,  and  com¬ 
munications  times  for  each  kind  of  request,  calculate  the  total  real-time  to  be  used  per  second 
for  the  series  of  requests.  If  this  number  exceeds  the  maximum  computational  power/commu- 
nication  bandwidth  allocated  to  this  type  of  request  response  pair  per  second,  another  solution 
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Caution,  this  is  only  valid  if  the  server  does  not  idle  during  the  performance  of  this  activity;  if  it  does,  another 
activity  might  be  able  to  utilize  this  time. 


must  be  devised.  If  it  does  not,  determine  whether  there  is  a  great  deal  of  slack  in  your  numbers, 
in  case  your  estimates  were  not  accurate.  If  there  is  not  a  great  deal  of  slack,  analyze  or  simulate 
the  application  in  greater  detail.  If  so,  continue  implementation  remaining  aware  that  the  con¬ 
founding  factors  may  render  your  analysis  invalid. 

5.2  FINAL  COMMENTS 

To  determine  the  best  design  for  a  distributed  application,  you  must  have  or  obtain  an 
understanding  of  the  parameters  that  affect  your  choices  of  how  to  divide  your  application  for 
execution  on  distributed  platforms.  It  may  be  necessary  to  iterate  prototyping  and  calculation 
in  order  to  achieve  confidence  that  you  understand  the  characteristics  of  your  suite  of  applica¬ 
tions,  your  production  Servers,  and  your  production  Clients.  The  more  types  of  requests,  the 
more  varied  your  applications,  and  the  more  diverse  your  collection  of  platforms,  the  greater 
the  work  will  be  to  understand  the  interactions  of  all  the  components. 


LIST  OF  ACRONYMS 


API 

Application  Programming  Interface 

ATM 

Asynchronous  Transfer  Mode 

COE 

Common  Operating  Environment 

CORBA 

Common  Object  Request  Broker  Architecture 

C-S 

Client  Server 

DARPA 

Defense  Advamced  Research  Projects  Agency 

DCE 

Distributed  Computing  Environment 

DCOM 

Distributed  Component  Object  Model 

DCWG 

Distributed  Computing  Working  Group 

DII 

Defense  Information  Infrastructure 

DISA 

Defense  Information  Systems  Agency 

GCCS 

Global  Command  and  Control  System 

IDL 

Interface  Definition  Language 

LAN 

Local  Area  Network 

LPC 

Local  Procedure  Call 

ms 

Milliseconds 

ns 

Nanoseconds 

OG 

Open  Group 

OMG 

Object  Management  Group 

OO 

Object-Oriented 

ORB 

Object  Request  Broker 

OSF 

Open  Software  Foundation 

RPC 

Remote  Procedure  Call 

TCA 

Track  Correlation 

TCP/IP 

Transmission  Control  Protocol/Intemet  Protocol 

TCS 

Track  Correlation  Service 

WAN 

Wide  Area  Network 

|LIS 

Microseconds 

APPENDIX  A.  GLOSSARY 


Interface.  A  specification  of  the  external  properties  of  an  object  including  attributes  and  meth¬ 
ods  of  the  object.  Attributes  and  parameters  of  methods  indicate  their  type  and  whether  they  are 
input,  output,  or  inout  attributes/parameters.  Methods  provide  a  “signature”  which  specifies 
returned  type,  object  name,  method  name,  and  a  list  of  parameter  types. 

Marshalling.  The  process  of  assembling  arguments  to  a  remote  procedure  call  into  a  canoni¬ 
cal  data  structure  which  can  be  transmitted  to  a  remote  machine  for  use. 

Method.  A  procedure  provided  by  an  object  for  the  manipulation  of  that  object’s  internal  state, 
which  may  invoke  other  methods  internal  to  or  external  to  the  object. 

Microsecond.  One  one-millionth  (1/1,000,000)  of  a  second. 

Millisecond.  One  one-thousandth  (1/1, OCX))  of  a  second. 

Nanosecond.  One  one-billionth  (1/1,000,000,000)  of  a  second. 

It'ack.  A  description  of  location  as  a  function  of  time;  may  result  from  data  obtained  from 
optical,  electrical,  acoustic,  thermal,  or  visual  sensing  as  correlated  by  the  track  correlation  pro¬ 
cess  and  as  stored  in  a  track  record  in  a  Track  Data  Base  (See  Section  C.3.5  for  an  interface 
definition). 

Unmarshalling.  The  process  of  converting  a  data  structure  provided  by  a  remote  machine  into 
a  list  of  arguments  to  be  used  by  a  procedure  call  on  the  local  machine. 


APPENDIX  B.  ATTACHMENTS 
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Efficiency:  (LPC+Server  Work)/(RPC+Server  Work) 
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Server  Work  (In  LPC  Units) 


APPENDIX  C.  SOURCE  CODE  FOR  TESTS 


C.1  DOUBLE  PRECISION  TIMER  SOURCE  ROUTINES 
C.1.1  CLIENT 


//  Client. C 

//  allow  the  defintion  of  the  _individual_  system  exceptions  to  be  visible. 
#define  EXCEPTIONS 

#include  "filter. hh' 

#include  <stream.h> 

//  for  extern  "exit" 

#include  <stdlib.h> 

//  for  timing 
# include  <sys/time.h> 


#include  "ProcFilt.h" 

ProcessFilter  PFilter;//  create  one  instance  of  the  per-process  filter. 
//  This  will  monitor  calls  to  and  from  this 
//  address  space. 

int  main  (int  argc,  char  **argv)  { 
unsigned  long  value  =  0; 
double  temp  ; 
inc_var  bVar; 

hrtime_t  start_hires,  end_hires,  diff_hires,  junk,  Svr_time [ 15000] ; 
int  maxS ; 

//  need  a  hostname  argument; 
if  (argc  <  2)  { 

cerr  «  "usage:"  <<  argv[0]  «  "  <hostname>"  <<  endl; 
exit (1 ) ; 


//  now  try  to  bind  to  the  target  object. 

//see  how  long  a  bind  takes 
try  { 

cout  <<  "TTTD:  Attempting  Bind..."  «  endl; 

start_hires  =  gethrtime(); 

bVar  =  time: :_bind  ( " :xf ilter" , argv[l) ) ; 

end_hires  =  gethrtime { ) ; 

diff_hires  =  end_hires  -  start_hires ; 


ns"  <<  endl; 


cout  «  "TTTR:  Bind  time:  "  «  diff_hires  «  " 
cout  <<  "Start  value:  "  «  value  «  "\n"; 

} 

catch  (CORBA: : SystemException  &sysEx)  { 

cerr  «  "Unexpected  system  exception”  «  endl; 
cerr  «  SeSysEx; 

cerr  «  "Bind  failed"  «  endl; 
exit (1) ; 

}  catch  (...)  { 

//  the  bind  failed 
cerr  «  "Unexpected  exception  :  bind  failed"  «  endl; 
exit (1) ; 

} 


for  (int  i  =  0;  i  <  10000;  i++)  { 
try  { 

temp  =  bVar->hr_time  (value) ; 

Svr_time [ i ]  =  temp ; 

}  catch  (...)  { 

//  should  0et  no  exceptions: 
cout  <<  "ExceptionXn" ; 

cout  «  "call  to  get  time  failed"  «  endl; 
exit (1) ; 


} 


for(i=0;  i<orqprmI-l  ;  i++) 

{  cout  «  orqprmACi]  <<  "->C1' 
orqprmi  =  0 ; 

for(i=0;  i<orqpomI-l  ;  i++) 

{  cout  «  orqpomAIi)  «  ”->C2" 
orcjpomi  =  0 ; 

for(i=0;  i<irpprml-l  ;  i++) 

{  cout  <<  irpprmAfi]  «  "->C7" 
irpprmi  =  0; 

for(i=0;  i<irppomI-l  ;  i++) 

{  cout  «  irppomA[i]  «  "->C8" 
irppomi  =  0 ; 

for(i=0;  i<10000;  i++) 


«  endl; 


«  endl; 


«  endl ; 


«  endl; 


); 


); 


}; 


{  cout  <<  Svr_time[i]  «  "->S9"  «  endl;  }; 
value  =  16000001; 

value  =  bVar->increment (value) ;  //Print  out  table 
value  =  1; 


return  0 ; 

) 


C.1.2  SERVER 

//  ma)ce  the  defintions  of  the  _individual_  system  exceptions  to  be  visiable. 
#define  EXCEPTIONS 
#include  <stream.h> 

♦include  "f ilter_i .hh" 


#include  <sys/time.h>  //  for  timing 


#include  "ProcFilt.h" 

//  for  extern  “exit” 

#include  <stdlib.h> 

ProcessFilter  Filter_instance;  //  install  per-process  filters, 
void  printtimes (void)  { 
int  i  ; 

for(i=0;  i<irqprml;  i++) 

cout  «  irqprmA  [  i  ]  «  "->S3”  «  endl; 

irqprmi  =  0 ; 

for(i=0;  i<irqpomI;  i++) 
cout  «  irqpomA[i]  <<  "->S4"  «  endl; 
irqpomi  =0; 

for(i=0;  i<orpprmI ;  i++) 
cout  «  orpprmAd)  <<  “->S5”  «  endl; 
orpprmi  =  0 ; 

for(i=0;  i<orppomI ;  i»+) 

cout  <<  orppomAfi]  <<  *->S6”  <<  endl; 
orppomi  =0; 

}; 

int  main (int  ,  char  ♦argv[))( 

hrtime_t  start_hires,  end_hires,  diff_hires,  jun)c;  //  ttttt 
//  create  the  target  object 
time_i  mytime; 

//  Export  the  server  to  the  networ)c 

//  tell  Orbix  that  the  server  has  completed  its  initialisation: 
cout  «  "TTTD;  Attempting  impl_is_ready . . . ’  «  endl; 

start_hires  =  gethrtimeO; 

COREA: :Orbix . impl_is_ready ( "xf ilter”) ; 
end_hires  =  gethrtimeO; 
diff_hires  =  end_hires  -  start_hires; 

cout  «  "TTTR:  impl_is_ready  time:  ”  <<  dif f_hires/1000000  <<  "  ms"  «  endl 

}  catch  (COREA: :SystemException  &sysEx)  { 
cerr  <<  "Unexpected  system  exception'  «  endl; 
cerr  «  ScsysEx; 

cerr  <<  "Unexpected  exception  :  impl_is_ready"  <<  endl; 
exit (1) ; 

}  catch  (...)  { 

//  got  an  exception  from  impl_is_ready ( ) 

err  <<  "Unexpected  exception  :  impl_is_ready"  «  endl ; 
exit ( 0 ) ; 

} 

cout  <<  "\n\nFilter  Server  shutdovm."  «  endl; 
return  0 ; 

} 


C-3 


C.1.3  FILTERS 


#define  EXCEPTIONS 
# include  <CORBA.h> 

♦include  <stream.h> 

♦  include  <sys/tiine.h> 

static  hrtime_t  orqprmA [ 15000 ] ; 

static  int  orqpnnl=0; 

static  hrtime_t  orgpomA [ 15000 ] ; 

static  int  orqpoml=0; 

static  hrtiine_t  irqpniiA[  15000]  ; 

static  int  irqpnnl=0; 

static  hrtime_t  irgpomA] 15000] ; 

static  int  irqpoml=0; 

static  hrtime_t  orpprmA] 15000] ; 

static  int  orpprml=0; 

static  hrtiine_t  orppomA  [  1 5 0 0 0 ]  ; 

static  int  orppoml=0; 

static  hrtime_t  irpprmA [ 15000 ] ; 

static  int  irppnnl=0; 

static  hrtime_t  irppomA [ 15000 ] ; 

static  int  irppoml=0; 


//  class  ProcessFilter  is  a  per-process  filter  which  just  outputs  messages  as 
//  it  sees  requests. 

class  ProcessFilter  :  public  CORBA: :Filter  { 

public: 

//  REQUESTS 


//  an  out  going  call,  before  it  has  been  sent  out  of  the  addr  space; 


CORBA: : Boolean  outRequestPreMarshal 

hrtime_t  orqprm; 

orqprm  =  gethrtime ( ) ; 
orqprmA [ orqprmi ]  =  orqprm ; 
orqprmi  +=  1; 
return  1 ; 


(CORBA: : Requests  r, 

CORBA: : Environments) 


) 


{ 


//an  out  going  call,  before  it  has  been  sent  out  of  the  addr  space: 
CORBA; : Boolean  outRequestPostMarshal  (CORBA: : Requests  r, 

CORBA: : Environments)  { 


hrtime_t  orqpom; 

orqpom  =  gethrtime(); 
orqpomA [ orqpomi ]  =  orqpom; 
orqpomi  +=  1 ; 


return  1 ; 

) 


//an  incoming  call,  before  it  is  sent  to  the  target  object 
int  inRequestPreMarshal  (CORBA :: Requests  r, 

CORBA: : Environments)  { 

hrtime_t  irqprm; 

irqprm  =  gethrtime ( ) ; 


irqpnnA[irqpni\I]  =  irqprm; 
irqprmi  +=  1; 
return  1 ; 

} 

//  an  incoming  call,  before  it  is  sent  to  the  target  object 
CORBA:  :Boolean  inRequestPostMarshal  (CORBA:  iRecjuestSi  r, 

CORBA: : Environments)  { 

hrtime_t  irqpom; 

irqpom  =  gethrtime(); 
irqpomA[irqpomI]  =  irqpom; 
irqpomi  +=  1; 

return  1 ; 


} 

//  REPLIES 


//  an  out  going  call,  before  it  has  been  sent  out  of  the  addr  space: 
CORBA: :Boolean  outReplyPreMarshal  (CORBA: :Request&  r, 

CORBA: : Environments)  { 


hrtime_t  orpprm; 

orpprm  =  gethrtime { ) ; 
orpprmA [ orpprmi ]  =  orpprm; 
orpprmi  +=  1; 


return  1; 


// 


) 

an  out  going  call,  before  it  has  been  sent  out  of  the  addr  space: 
CORBA: :Boolean  outReplyPostMarshal  (CORBA: :ReguestS  r, 

CORBA: : Environments)  { 


hrtime_t  orppom; 

orppom  =  gethrtime ( ) ; 
orppomA [ orppomi 1  =  orppom; 
orppomi  +  =  1 ; 


return  1; 

} 


//  an  incoming  call,  before  it  is  sent  to  the  target  object 
CORBA: :Boolean  inReplyPreMarshal  (CORBA: :RequestS  r, 

CORBA: : Environments)  { 

hrtime_t  irpprm; 

irpprm  =  gethrtime ( ) ; 
irpprmA [ irpprmi ]  =  irpprm; 
irpprmi  +=  1 ; 


return  1; 

) 


//  an  incoming  call,  before  it  has  been  sent  to  the  target  object 
CORBA: : Boolean  inReplyPostMarshal  (CORBA: :RequestS  r, 

CORBA: : Environments)  { 

hrtime_t  irppom; 

irppom  =  gethrtime ( ) ; 


irppomA [ irppoml ]  =  irppom; 
irppoml  +=  1; 


return  1 ; 

} 

); 

C.1.4  OBJECT  INCLUDES 

tifndef  filter_ih 
tdefine  filter_ih 

♦include  "filter. hh' 

class  time_i:  public  virtual  incBOAImpl  { 
public : 

time_i();  //  ctor 

virtual  -time_i ( ) ;  //  dtor 

virtual  CORBA:  : Double  hr_tiine  (CORBA:  :ULong  vin,  CORBA ::  Environment  &IT_env=COR- 
BA: :default_environment)  ; 

}; 

#endif 

C.1.5  OBJECT  METHODS 

♦include  "f ilter_i .hh' 

♦  include  <stre2un.h> 

♦include  <sys/types .h> 

♦include  <sys/time.h> 
void  printtimes (void) ; 

time_i : : time_i ( )  { ) ; 
time_i : : -time_i ( )  {); 

CORBA Double  time_i::  hr_time  (CORBA;  :ULong  vin,  CORBA:  : Environment  ScIT_env)  { 
if  (vin  1=  16000001) 
return  gethrtime { ) ; 
else  printtimes 0 ; 

} 

C.1.6  INTERFACE  DEFINITION 

//a  simple  IDL  interface:  time.  Objects  of  this  interface  provide  an 
//  operation  'hr_time'  which  takes  an  unsigned  long  value  which  may  signal 
//  termination  of  the  server  and  returns  the  double  real-time  in  nanoseconds 
//  (if  vin  does  not  signal  termination  of  the  server). 

interface  time  {double  hr_time  (in  unsigned  long  vin);}; 


C.2 


CHARACTER  SEQUENCE  SOURCE  ROUTINES 


C.2.1  CLIENT 

//  client. C 

//  This  demonstrate  the  use  of  both  per-process  and  per-object  filtering. 
//  Classes  ProcessFilter  and  preProces  demonstrate  per-object  filtering. 

//  Classes  fiterPre  and  filterPost  demonstrate  per-object  filtering. 

//  allow  the  defintion  of  the  _individual_  system  exceptions  to  be  visible 
#define  EXCEPTIONS 

#include  ”Trax2.hh' 

#include  <stream.h> 

//  for  extern  "exit* 

#include  <stdlib.h> 

//  for  timing 
#include  <sys/time.h> 


♦include  "ProcFilt.h" 

ProcessFilter  PFilter;//  create  one  instance  of  the  per-process  filter. 

//  This  will  monitor  calls  to  and  from  this 
//  address  space. 

int  main  (int  argc,  char  **argv)  { 
long  value  =  0; 

hrtime_t  start_hires,  end_hires,  diff_hires,  Svr_time[ 15000] ; 
double  time; 

Trax_var  bVar; 
int  maxS; 

//  need  a  hostname  argument; 
if  (argc  <  2)  { 

cerr  <<  "usage:"  «  argv[0]  «  "  <hostname>"  «  endl ; 
exi t (1 ) ; 

) 

//  now  try  to  bind  to  the  target  object. 

//see  how  long  a  bind  takes 
try  { 

cout  «  "TTTD:  Attempting  Bind..."  «  endl; 

start_hires  =  gethrtime ( ) ; 

bVar  =  Trax::_bind  ( " : sttracks" ,argv[l] ) ; 

end_hires  =  gethrtime ( ) ; 

diff_hires  =  end_hires  -  start_hires; 

cout  <<  "TTTR;  Bind  time:  "  «  diff_hires  «  "  ns"  «  endl  ; 
cout  «  "Start  value:  "  «  value  «  "\n"; 

) 

catch  (CORBA:  :  SystemException  SisysEx)  { 

cerr  «  "Unexpected  system  exception"  «  endl; 
cerr  <<  SiSysEx; 


cerr  <<  "Bind  failed"  «  endl; 
exit (1) ; 

}  catch  (...)  { 

//  the  bind  failed 

cerr  <<  "Unexpected  exception  :  bind  failed"  «  endl; 
exit (1)  ; 

) 

time  =  0 ; 
char*  str; 

for  (int  i  =  0;  i  <  10000;  i++)  { 
try  { 

str=bVar->get  (value,  time) ; 

Svr_time[i]  =  time; 

CORBA: : string_free (str) ; 

} 

catch  (CORBA:  : SystemException  StsysEx)  { 

cerr  «  "Unexpected  system  exception"  «  endl; 

cerr  <<  &sysEx; 

cerr  <<  "  (flhy?  "  «  endl; 

exit (1) ; 

} 

catch  (...)  { 

//  should  get  no  exceptions: 

cout  <<  "ExceptionXn" ; 

cout  «  "call  to  Trax  failed"  «  endl; 

exit (1) ; 

) 

} 


for(i=0;  i<orqprmI-l  ;  i++) 

{  cout  «  orcjprmA[i]  <<  "->C1"  «  endl; 
orqprmi  =  0 ; 

for(i=0;  i<orqQpomI-l  ;  i++) 

{  cout  «  orgpomAd)  <<  "->C2"  «  endl; 
orcjpomi  =  0  ; 

for(i=0;  i<irpprml-l  ;  i++) 

(  cout  «  irpprmA[i]  <<  "->C7"  «  endl; 
irpprmi  =  0; 

for(i=0;  i<irppomI-l  ;  i++) 

{  cout  «  irppomAd]  «  "->C8"  «  endl  ; 
irppomi  =  0 ; 

for(i=0;  i<10000;  i++) 

(  cout  <<  Svr_time[i]  <<  "->S9"  «  endl; 


); 


); 


}; 


); 


); 


value  =  16000001; 

bVar->print (value) ;  //Print  out  table 
value  =  1; 


return  0; 

) 


C.2.2  SERVER 


//  ma)ce  the  defintions  of  the  _individual_  system  exceptions  to  be  visiable. 
#define  EXCEPTIONS 


#include  <string.h> 
# inc lude  " Tr ax2_i . h 


#include  <sys/time.h>  //  for  timing 

Sinclude  "ProcFilt.h' 

//  for  extern  "exit' 

#include  <stdlib.h> 


ProcessFilter  Filter_instance;  //  install  per-process  filters, 
void  printtimes (void)  { 
int  i  ; 

for(i=0;  i<irqprml;  i++) 

cout  «  irqprmA[i]  «  "->S3'  «  endl; 
irqprmi  =  0; 

for(i=0;  i<irqpomI;  i++) 

cout  «  irqpomA[i)  «  "->S4'  «  endl; 
irqpomi  =0; 

for(i=0;  i<orpprmI;  i++) 

cout  «  orpprmAfi]  «  "->S5'  «  endl; 


orpprmi  =  0 ; 

for(i=0;  i<orppomI;  i++) 

cout  «  orppomAti]  «  "->36*  «  endl; 
orppomi  =0; 


); 


int  main (int  ,  char  *argv[]){ 

hrtime_t  start_hires,  end_hires,  diff_hires  ;  //  ttttt 

//  create  the  string 
char  *tr)c  =  CORBA:  :string_alloc  (938)  ; 

strcpy  ( tr)c,  "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghi  j)clmnopqrstuvwx" 
"  ABCDEFGHIJKLlMNOPQRSTUVWXYZabcde  f  ghi  j  )clmnopgr  s  tuvwx  ' 

"  ABCDEFGHIJKLMNOPQRSTUVWXYZabcdef  ghi  j  jclmnopqrs  tuvwx  ' 
"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijJclmnopqrstuvwx" 
"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghij)tlmnopqrstuvwx' 
"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijlclmnopqrEtuvwx’ 

”  ABCDEFGHIJKLMNOPQRSTUVWXYZabcde  f  ghi  j  )tlmnopqr  s  tuvwx  ' 
"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghij)clmnopqrstuvwx' 

"  ABCDEFGHIJKLMNOPQRSTUVWXYZabcdef  ghi  j  l^lmnopqrs  tuvwx  " 

”  ABCDEFGHIJKLMNOPQRSTUVWXYZabcdef  ghi  j)clmnopqrs  tuvwx' 
"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwx' 
"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghij)clmnopqrstuvwx' 
"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghij]clmnopqrs  tuvwx' 
"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdef  ghi  jlclmnopqrs  tuvwx" 

”  ABCDEFGHIJKLMNOPQRSTUVWXYZabcdef  ghi  j)clmnopqrs  tuvwx" 

"  ABCDEFGHIJKLMNOPQRSTUWIXYZabcdef  ghi  jjclmnopqrs  tuvwx" 

"  ABCDEFGHIJKLMNOPQRSTUVWXYZabcdef  ghi  j  jclmnopqrs  tuvwx  " 
"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijiclmnopqrstuvwx' 
"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghi  j]c" )  ; 

//  create  the  target  object 


Trax_i  mytrax  ( tr)c)  ; 


//  Export  the  server  to  the  network 
// 

try  { 

//  tell  Orbix  that  the  server  has  completed  its  initialisation: 
cout  <<  "TTTD:  Attempting  impl_is_ready . . . '  «  endl; 
start_hires  =  gethrtime ( ) ; 

CORBA: : Orbix. impl_is_ready( “sttracks* ) ; 
end_hires  =  gethrtime ( ) ; 
diff_hires  =  end_hires  -  start_hires; 

cout  «  "TTTR:  impl_is_ready  time:  "  «  dif f_hires/1000000  « 

)  catch  (CORBA: : SystemException  AsysEx)  { 

cerr  «  "Unexpected  system  exception'  «  endl; 
cerr  «  AsysEx; 

cerr  «  "Unexpected  exception  :  impl_is_ready"  «  endl; 
exit (1) ; 

}  catch  (...)  { 

//  got  an  exception  from  impl_is_ready ( ) 

cerr  «  “Unexpected  exception  :  impl_is_ready"  «  endl ; 

exit (0) ; 

} 

cout  «  "\n\nFilter  Server  shutdown.'  «  endl; 

CORBA: : string_free ( trk) ; 
return  0 ; 


C.2.3  OBJECT  INCLUDES 


#ifndef  Trax2_ih 
#define  Trax2_ih 

# inc lude  " Trax2 . hh " 

♦include  <string.h> 

class  Trax_i :  public  virtual  TraxBOAImpl  { 
char  *m_track; 
public : 

Trax_i(char  *str) ; 

-Trax_i ( ) ; 

virtual  void  print  (CORBA: : Long  signal,  CORBA :: Environment 
BA: : def ault_environment ) ; 

virtual  char'  get  (CORBA: :Long  index,  CORBA: :Double&  time,  CORBA 
&IT_env=CORBA: : default_environment)  ; 

}; 


ms"  <<  endl; 


Sc  IT_env=COR  - 
:  : Environment 


#endi f 


C.2.4  OBJECT  METHODS 


#define  EXCEPTIONS 
# include  <CORBA.h> 
tinclude  “Trax2_i.h' 

# include  <sys/times .h> 

#include  <stdlib.h> 

# include  <streain.h> 
void  printtimes (void) ; 

Trax_i : :Trax_i (char  *str) { 

m_trac)c  =  CORBA:  :string_alloc  (938)  ; 
strcpy  (in_trac)c,  str )  ; 

cout  «  strlen(m_trac]c)  «  "=  trade  length*  <<  endl; 

}; 

Trax_i : : ~Trax_i  ( ) { 

CORBA:  :  string_free  (m_trac)c)  ; 

); 

void  Trax_i  :  :  print  (CORBA;:  Long  signal,  CORBA:  :  Environment  SeIT_env)  { 
printtimes ( ) ; 
exit (1) ; 

}; 


char*  Trax_i : :  get  (CORBA; :Long  index,  CORBA: : Doublet  time,  CORBA :: Environment  &IT_env)  ( 
int  i  ; 

char*  temp  =  CORBA::string_alloc(938); 
strepy (temp,m_track)  ; 
time  =  gethrtime ( ) ; 
return  temp; 

}; 


C.2.5  INTERFACE  DEFINITIONS 

typedef  string<938>  VtTrac)c; 

interface  Trax  { 

void  print  (in  long  signal); 

void  get  (in  long  index,  out  VtTrac)e  trac)c,  out  double  time)  ; 

}; 

C.3  VTPLATFORM  SOURCE  ROUTINES 
C.3.1  CLIENT 

//  Client. C 

//  This  demonstrate  the  use  of  both  per-process  and  per-object  filtering. 

//  Classes  ProcessFilter  and  preProces  demonstrate  per-object  filtering. 

//  Classes  fiterPre  and  filterPost  demonstrate  per-object  filtering. 

//  allow  the  defintion  of  the  _individual_  system  exceptions  to  be  visible. 
#define  EXCEPTIONS 

#include  "Trax2.hh" 
tinclude  <stream.h> 


C-11 


//  for  extern  "exit" 

#include  <stdlib.h> 

//  for  timing 
# include  <sys/time.h> 

#include  "ProcFilt.h" 

ProcessFilter  PFilter;//  create  one  instance  of  the  per-process  filter. 

//  This  will  monitor  calls  to  and  from  this 
//  address  space. 

int  main  (int  argc,  char  **argv)  { 
long  value  =  0 ; 

Trax_var  bVar; 

VtPlatformTrack  VtX; 

hrtime_t  start_hires,  end_hires,  diff_hires,  Svr_time [ 15000 ) ; 
double  time; 
int  maxS; 

//  need  a  hostname  argument; 
if  (argc  <  2)  { 

cerr  <<  "usage:"  <<  argv[0]  «  "  <hostname>"  <<  endl; 
exit (1) ; 

} 

//  now  try  to  bind  to  the  target  object. 

//see  how  long  a  bind  takes 
try  { 

cout  <<  "TTTD;  Attempting  Bind..."  «  endl; 

start_hires  =  gethrtime ( ) ; 

bVar  =  Trax: :_bind  ( ” :xtracks" , argv[l] ) ; 

end_hires  =  gethrtimeO; 

diff_hires  =  end_hires  -  start_hires; 

cout  «  "TTTR:  Bind  time:  "  «  diff_hires  «  ”  ns"  «  endl; 
cout  <<  "Start  value;  "  «  value  «  "\n"; 

) 

catch  (CORBA:  :SystemException  ScsysEx)  { 

cerr  «  "Unexpected  system  exception'  «  endl; 
cerr  <<  &sysEx; 

cerr  <<  "Bind  failed"  <<  endl; 
exit { 1) ; 

}  catch  (...)  { 

//  the  bind  failed 

cerr  <<  "Unexpected  exception  :  bind  failed'  «  endl; 
exit (1 ) ; 


time  =  0 ; 

for  (int  i  =  0;  i  <  10000;  i++)  { 
try  { 

bVar->get  (value,  VtX,  time) ; 
Svr_time[i)  =  time; 

)  catch  (...)  { 
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//  should  get  no  exceptions: 

cout  <<  "ExceptionNn" ; 

cout  «  "call  to  Trax  failed"  «  endl; 

exit (1) ; 


} 


for(i=0;  i<orqpr7nI-l  ;  i++) 

{  cout  «  orqprmA[i]  <<  "->C1"  «  endl;  } ; 
orqprml  =  0 ; 

for(i=0;  i<orqpomI-l  ;  i++) 

{  cout  «  orqpomA[i]  <<  "->C2"  «  endl;  ); 
orqpoml  =  0 ; 

for(i=0;  i<irppntil-l  ;  i++) 

{  cout  «  irppnnA[i]  <<  "->C7"  «  endl;  }; 
irpprml  =  0 ; 

for(i=0;  i<irppomI-l  ;  i++) 


{  cout  «  irppomAfi]  <<  "->C8"  «  endl;  ); 
irppomi  =  0 ; 
for(i=0;  i<10000;  i++) 

{  cout  «  Svr_tiine[i]  <<  '->S9'  «  endl;  ); 
value  =  16000001; 

bVar->print (value) ;  //Print  out  table 
value  =  li¬ 


re  turn  0; 

} 


C.3.2  SERVER 


//  ina)ce  the  defintions  of  the  _individual_  system  exceptions  to  be  visiable. 
#define  EXCEPTIONS 
#include  <stream.h> 

# include  "Trax2_i.h' 

#include  <sys/time.h>  //  for  timing 

#include  "ProcFilt.h" 

//  for  extern  "exit" 

#include  <stdlib.h> 


ProcessFilter  Filter_instance;  //  install  per-process  filters, 
void  printtimes (void)  { 
int  i  ; 

for(i=0;  i<irqprml ;  i++) 

cout  <<  irc3prmA[i]  «  "->S3"  «  endl; 
irqprmi  =  0 ; 

for(i=0;  i<irqpomI;  i++) 

cout  <<  irqpomA[i) 
irqpoml  =0; 


<< 


->S4"  «  endl; 


for(i=0;  i<orppnnI;  i++) 

cout  «  orpprmAfi]  «  "->S5*  «  endl; 
orpprml  =  0 ; 

for(i=0;  i<orppomI;  i++) 

cout  «  orppoinA[i]  <<  ”->S6"  «  endl; 
orppomi  =0; 

}; 


int  maindnt  ,  char  *argv[]){ 

hrtime_t  start_hires,  end_hires,  diff_hires  ;  //  tttTT 

//  create  the  target  object 

Trax_i  mytrax; 


// 

//  Export  the  server  to  the  network 
// 

try  { 


//  tell  Orbix  that  the  server  has  completed  its  initialisation: 
cout  «  "TTTD:  Attempting  impl_is_ready . . . '  «  endl ; 
start_hires  =  gethrtime ( ) ; 

CORBA : : Orbix . impl_is_ready ( "xtracks " ) ; 
end_hires  =  gethrtime ( ) ; 
diff_hires  =  end_hires  -  start_hires ; 

cout  «  "TTTR:  impl_is_ready  time:  "  «  dif f_hires/1000000  <<  ”  ms'  <<  endl; 
}  catch  (CORBA: ;SystemException  tsysEx)  { 

cerr  «  "Unexpected  system  exception'  «  endl; 
cerr  «  &sysEx; 

cerr  «  "Unexpected  exception  :  irapl_is_ready'  «  endl; 
exit (1) ; 

}  catch  (...)  { 

//  got  an  exception  from  impl_is_ready ( ) 

cerr  «  "Unexpected  exception  :  impl_is_ready'  «  endl ; 

exit (0 ) ; 

} 

cout  «  "\n\nFilter  Server  shutdown.'  «  endl; 


return  0 ; 


C.3.3  OBJECT  INCLUDES 


#ifndef  Trax2_ih 
#define  Trax2_ih 

# include  "Trax2.hh" 

class  Trax_i :  public  virtual  TraxBOAImpl  { 
public : 

VtPlatf ormTrack  VtP; 

Trax_i ( ) ; 

~Trax_i ( ) ; 

virtual  void  print  (CORBA: :Long  signal,  CORBA: :Environment  &IT_env=COR- 
BA: :default_environment)  ; 


virtual  void  get  (CORBA: :Long  index,  VtPlatfonnTrack&  track,  CORBA Doubles  time,  COR 
BA ::  Environment  &IT_env=CORBA:  :default_environinent)  ; 


#endif 


C.3.4  OBJECT  METHODS 

#define  EXCEPTIONS 
#include  ''Trax2_i.h' 

#include  <stdlib.h> 

#include  <sys/times .h> 

# include  <stream.h> 
void  printtimes (void) ; 

Trax_i : : Trax_i ( ) { } ; 

Trax_i : : -Trax„i ( ) { ) ; 

void  Trax_i : :  print  (CORBA: : Long  signal,  CORBA: : Environment  &IT_env)  { 
printtimes ( ) ; 
exi t ( 1 ) ; 

} 

void  Trax_i : :  get  (CORBA: : Long  index,  VtPlatformTrackS  track,  CORBA: : Doubles  time,  CORBA: :En 
vironment  &IT_env)  { 

VtP. data. quantity  =1; 
time=gethrtime ( ) ; 

) 


C.3.5  VTTRACK  INTERFACE  DEFINITIONS 


// 


//  NEW  TRACK  STRUCTURES 

//============================= 

// 

//  SYSID 
//  VtSysid 
//  VtTrackStatus 

/ /  VtAou 
/ /  VtReport 
//  VtShortReport 
//  VtTracker 
//  VtElintStats 
//  VtRadReport 
//  VtlllData 
//  VtlllReport 
//  VtRadAndReport 
//  VtSignaReport 
//  VtTechData 


/ /  VtRemarks 


/ /  VtCandidate 
//  VtCandidateList 

/ /  VtTrknum 
//  VtTrackHeader 
//  VtTraclcSearch 

//  VtPlatfomriData 
/ /  VtLinkData 
//  VtSpa25Data 
//  VtLateralTellData 
//  VtEmitterData 
//  VtAcousticData 
//  VtLandData 
/ /  VtUnitData 

//  VtPlatformTrack 
//  VtLinkTrack 
//  VtSpa25Track 
//  VtLateralTellTrack 
//  VtEmitterTrack 
//  VtAcousticTrack 
//  VtLandTrack 
//  VtUnitTrack 


#define  VT_MAX_RTN  12 
#define  VT_MAX_TRACKER_rptS  10 

#define  VT_MAX_TRACK_SIZE  912 

tdefine  VT_MAX_LRAW  50 

//  LINKll  data  types  (0-15) 
#define  EMPTY_TYPE  0 
#define  ACDS_TYPE  1 
#define  LINK11_TYPE  2 
#define  LINK14_TYPE  3 
#define  LINK16_TYPE  4 
#define  LN2_TYPE  5 
♦define  CEC_TYPE  6 
♦  define  LATTL_TYPE  7 

//  Platform  data  types  (0-15) 
♦define  TBMD_TYPE  1 
♦define  SITE_TYPE  2 


//  Track  amplification  -  other  database  numbers  (0-15) 

♦define  DB_NUM_TYPE_EMPTY  0 

♦define  DB_NUM_TYPE_PIN1//  PIN  number  (PN:) 

♦define  DB_NUM_TYPE_DEV2 / /  Developmental  Site/Equipment  number  (DV:) 
♦define  DB_NUM_TYPE_BE  3//  Basic  Encyclopedia  number  (BE:) 


#define  DB_NUM_TYPE_GENERIC4/ /  Generic  number  (GN:) 

idefine  DB_NUM_TYPE_AID5//  AID  number  (MIIDS/IDB  derived)  (ID:) 

#define  DB_NUM_TYPE_VEHICLE6//  Vehicle  ID 

//  Raw  data  types 
ttdefine  RAW_EMPTYEMPTY_TYPE 
#define  RAW_ACDSACDS_TYPE 
#define  RAW_LINK11LINK11_TYPE 
#define  RAW_LINK14LINK14_TYPE 
#define  RAW_LINK16LINK16_TYPE 
#define  RAW_LN2LN2_TYPE 
#define  RAW_CECCEC_TYPE 
#define  RAW_LATTLLATTL_TYPE 

#define  RAW_POS20 


#define  VT_ALERT_LEN  3 
#define  VT_ALERT_WORD_LEN  20 
#define  VT_BE_NUMBER_LEN  12 
#define  VT_CALLSIGN_LEN  20 
#define  VT_CN_LEN  15 
#define  VT_CATEGORY_LEN  3 
#define  VT_CD_LEN  8 
#d6fine  VT_CL_LEN  11 
#define  VT_CHXREF_LEN  3 
♦define  VT_CLASS_LEN  24 
♦define  VT_CG_LEN  6 
♦define  VT_DI_LEN  4 
♦define  VT_FCODE_LEN  2 
♦define  VT_FDI_LEN  4 
♦define  VT_FLAG_LEN  2 
♦define  VT_HOME_BASE_LEN  20 
♦define  VT_HULL_LEN  6 
♦define  VT_IFF_LEN  3 
♦define  VT_MT_LEN  3 
♦define  VT_MSG_TYPE_LEN  6 
♦define  VT_NTDS_LEN  5 
♦define  VT_PDDG_LEN  2 
♦define  VT_PIF_CODE_LEN  4 
♦define  VT_RAID_LEN  5 
♦define  VT_SCONUM_LEN  8 
♦define  VT_SHORTNAME_LEN  10 
♦define  VT_SN_LEN  8 
♦define  VT_SOURCE_LEN  6 
♦define  VT_SUBJ_ID_LEN  24 
♦define  VT_SERIAL_LEN  5 
♦define  VT_SUBJ_TYPE_LEN  6 
♦define  VT_SUBORD_LEN  24 
♦define  VT_SUFFIX_LEN  5 
♦define  VT_THREAT_LEN  3 
♦define  VT_TYPE_LEN  6 
♦define  VT_NTYPE_LEN  6 
♦define  VT_UIC_LEN  6 
♦define  VT_UNIT_IDENT_LEN  26 


#define  VT_XREF_LEN  4 
♦define  VT_PLOT_ID_LEN  8 


typedef  struct  A1  { 

long  timestamp; 
long  record; 
long  machine; 
long  database; 
long  spare; 

}  SYS ID  ; 

typedef  struct  A2  { 

char  serial [20]; 
)  VtSysid; 


typedef  struct  A3  { 
long  dtg  ; 

long  ctcno; 
char  serial  [20]; 
}  VtTagInf ormation; 


//  DTG  from  contributing  report 

//  Contact  serial  number  from  contributing  report 
//  UID  from  track  ovmer 


typedef  struct  A4  { 

1  ong  gr oup_mas  k ; 
long  lastchange; 


//  group  membership  bit-mask 
/ /  time  last  updated  in  any  way  by  Tdbm 


long  rpts ; 
long  maxrpts; 


//  Current  number  of  reports 
//  Max  reports  stored  on  this  tracks 


short  plot_id[VT_PLOT_ID_LEN] ; //  symbol  plot  id 
unsigned  short  correlation;//  Status  from  Correlator 
char  toi_state;  //  TOI  status  flag 

char  ownship;  //  flag  for  own  ship 


long  mask; 
unsigned  short 
unsigned  short 
unsigned  short 
unsigned  short 
unsigned  short 
unsigned  short 
unsigned  short 
unsigned  short 
unsigned  short 


//  Status  mask  see  below 
ftn_cs;//  Checksum  on  FTN  (less  FTN  Command) 
ctc_cs;//  Checksum  on  CTC  data 
rmks_cs [4 ] ; //  Checksum  on  RMKS  data 
rig_cs;//  Checksum  on  RIG  data 
dep_cs ; / /  Checksum  on  DEP  data 
des_cs ; / /  Checksum  on  DES  data 
arr_cs ; / /  Checksum  on  ARR  data 
rtn_cs;//  Checksum  on  PAIR  data 
signa_cs;//  Checksum  on  SIGNA  data 


short  force_code  ; 

short  f orce_type_id  ;//  Unique  id  for  each  force  type 
)  VtTrackStatus ; 


//  Values  for  status  mask  field 


#define  VtTrackArchivedMaskdL  <<  0) 

#define  VtTrackProtectedMask (IL  <<  1) 

#define  VtTrackTargetFileMask(lL  «  2) 

#def ine  VtTrackResponsibleMask0x00000030 
#define  VtOTHResponsibleOxOOOOOOOO//  OTH  track 

#define  VtOTHMResponsibleOxOOOOOOlO//  OTH  track  held  by  Organic 
#define  VtCDSResponsible0x00000020//  Organic  track  held  by  OTH 
#define  VtLllResponsible0x00000030//  Lll  received  from  OTH 
#define  VtRTDReceivedMaskOx00000040/ /  Protection  and  responsibility 

//  received  in  a  RTD  line 

#define  VtNUTrackMask  0x00000100//  NUTrack  of  non-Platform 

#define  VtFCSXmitMask  0x00000200  //  Transmit  updates  to  FCS 

#define  VtFCSAncestorMask0x00000400//  Track  is  from  FCS  database 

#define  Vt2LllXmitMask  0x00000800  //  2-way  Link-11  track 

#define  Vt2LllTrkMask  0x00001000  //  2-way  Link-11  track 

#define  Vt2LllEmergMask  0x00002000  //  2-way  Link-11  Emergency  track 

#define  Vt2LllForceMask  0x00004000  //  2-way  Link-11  Force  Tell  track 

//  Sample  form  for  following  is;  isArchived(VtTrackStatusMask (trk) ) 

#define  isArchived(X)  (  (X)  &  VtTrackArchivedMask) 

#define  isProtected(X)  (  (X)  &  VtTrackProtectedMask) 

#define  isTargetFile (X) ( (X)  &  VtTrackTargetFileMask) 

#define  isOTHResponsible  (X)  (  (  (X)  &  VtTrac)cResponsibleMask)  ==  VtOTHResponsible) 
tdefine  isOTHMResponsible  (X)  (  (  (X)  &  VtTrac)cResponsibleMask)  ==  VtOTHMResponsible) 

#define  isCDSResponsible  (X)  (  (  (X)  &  VtTrac)cResponsibleMask)  ==  VtCDSResponsible) 

#define  isLllResponsible (X) ( ( (X)  &  VtTrackResponsibleMask)  ==  VtLllResponsible) 

#define  isRTDReceived (X) ( (X)  &  VtRTDReceivedMask) 

#define  isNUTrack (X) ( (X)  &  VtNUTrackMask) 

#define  isFCSXmitTrack (X)  ((X)  &  VtFCSXmitMask) 

#define  isFCSAncestor (X) ( (X)  &  VtFCSAncestorMask) 

#define  is2LllXmitTrack (X)  ((X)  &  Vt2LllXmitMask) 

#define  is2LllTrack (X)  {(X)  &  Vt2LllTrkMask) 

#define  is2LllEmergTrack {X)  ((X)  &  Vt2LllEmergMask) 

#define  iE2LllForceTrack (X)  ((X)  &  Vt2LllForceMask) 

//  Sample  form  for  following  is:  mask  =  VtTrackStatusMask(trk) ; 

//  VtSetArchived (mask) ; 

//  VtSetTrac)cArchiveMask(trk,mask)  ; 

#define  VtSetArchived  (X)  (  (X)  |=  VtTrac)cArchivedMask) 

#define  VtSetProtected (X) ( (X)  |=  VtTrackProtectedMask) 

#define  VtSetTargetFile (X) ( (X)  |=  VtTrackTargetFileMask) 

#define  VtSetOTHResponsible (X) ( (X)  =  {((X)  &  -VtTrackResponsibleMask)  |  VtOTHResponsible)) 
#define  VtSetOTHMResponsible (X) ( (X)  =  (((X)  &  -VtTrackResponsibleMask)  |  VtOTHMResponsible)) 
#define  VtSetCDSResponsible{X) { (X)  =  (((X)  &  -VtTrackResponsibleMask)  |  VtCDSResponsible)) 
#define  VtSetLllResponsible(X)  (  (X)  =  (((X)  &  -VtTraclcResponsibleMask)  |  VtLllResponsible)) 
♦define  VtSetRTDReceived (X) ( (X)  |=  VtRTDReceivedMask) 

♦define  VtSetNUTrack (X) ((X)  |=  VtNUTrackMask) 
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idefine  VtSetFCSXmit (X) 
tdefine  VtSetFCSAncestor (X) 
#define  VtSet2LllXinit  (X) 
#define  VtSet2LllTrk (X) 
#define  VtSet2LllEmerg (X) 
#define  VtSet2LllForce (X) 


((X)  1=  VtFCSXmitMask) 

(X)  1=  VtFCSAncestorMask) 

( (X)  1=  Vt2LllXmitMask) 

((X)  1=  Vt2LllTrkMask) 

({X)  1=  Vt2LllEmergMask) 

((X)  1=  Vt2LllForceMask) 


#define  VtClearArchived (X)  ((X)  &=  -VtTrackArchivedMask) 

#define  VtClearProtected(X)  (  (X)  &=  -VtTrackProtectedMask) 

#define  VtClearTargetFile (X)  ((X)  &=  -VtTrackTargetFileMask) 

#define  VtClearRTDReceived(X)  ( (X)  &=  -VtRTDReceivedMask) 

#define  VtClearTrackResponsibleMask (X) { (X)  &=  -VtTrackResponsibleMask) 


#define  VtClearNUTrack (X) 


( (X)  &=  -VtNUTrackMask) 


#define  VtClearFCSXmit (X) 
tdefine  VtClearFCSAncestor (X) 
#define  VtClear2LllXinit  (X) 
tdefine  VtClear2LllTrk (X) 
tdefine  VtClear2LllEmerg (X) 
tdefine  VtClear2LllForce (X) 


( (X)  &=  -VtFCSXmitMask) 

( (X)  &=  -VtFCSAncestorMask) 

((X)  &=  -Vt2LllXmitMask) 
((X)  &=  -Vt2LllTrkMask) 

( (X)  &=  -Vt2LllEmergMask) 
( (X)  &=  -Vt2LllForceMask) 


typedef  struct 

A5  { 

long 

typ; 

//  1-ell,  2-bbox,  3-lob 

float 

brg; 

/ /  bearing 

float 

al  ; 

//  meaning  of  al  &  a2  depend 

on  typ 

float 

a2; 

// 

}  VtAou  ; 

typedef  struct 

A6  { 

double 

lat ; 

//  latitude  in  degrees 

double 

Ing; 

//  longitude  in  degrees 

float 

cse; 

//  course  (DECT) 

float 

spd; 

//  speed  (KTS) 

float 

alt  ; 

//  altitude  (+FT/-FT) 

float 

anglelv; 

// 

angle  of  elevation/depression 

long 

dtg; 

//  Julian  seconds  since  1  Jan 

1970 

long 

rawdata ; 

//  raw  data  file  record  (ilog) 

long 

ctcno; 

//  contact  serial  number 

long 

datano ; 

//  associated  data  (serial  number) 

long 

trkrec ; 

//  trkrec  that  owns  report 

VtAou 

aou; 

//  area  of  uncertainty 

char 

sensor [7 ] ; 

// 

sensor 

char 

source [7]; 

// 

screen  field 

char 

rdf_rf [11] ; 

// 

freq  assoc  with  ew  report 

char 

callsign [9] ;  / / 

international  radio  callsign 

char 

xref [ 5 ] ; 

// 

cross-ref  flag  for  origin  of  report 

char 

chxref [4] ; 

// 

input  channel  cross-reference 

char 

classification; // 

classification  of  the  contact 

char 

releasibility ;  // 

releasibilty  of  the  contact 

char 

archived; 

// 

Marks  report  as  having  been  archived 

unsigned  short  mask;//  mask  (see  below) 
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long  key;  //  unique  relational  DB  key 

unsigned  short  checksxim; //  checksum  identification 
unsigned  short  checkkey;//  checksum  key 


char  error ; 
char  ci  [3]  ; 

alignment) 

}  VtReport ; 


//  report  received  with  cs  error 
//  Correlation  Index 

//  spare  bytes  (pad  for  4  byte 


//  VtReport .mask  defined  as  character  with  following  bit  masks 

#define  RPT_CHANNEL0x00000001  //  0  -  internal,  1  -  external 
#define  RPT_EXISTS0x00000002//  0  -  doesn't  exist,  1  -  exists 

#define  RPT_PERMANENTOx00000004//  for  NIPS  provided  information  to  prevent 

#define  RPT_PRECISION0x00000038//  3  bits  coordinate  precision  MTypes.h; 

//  {PosLatLong, PosLatLongDMS, PosLatLongDMST, PosMGR, PosUTM, PosGeoRef } 

#define  RPT_TYPE0x000001c0//  3  bits  TBMD  identification  (see  below) 


#define  VtReportTBMDMask  RPT_TYPE 
#define  VtReportTBMDLaunch  (IL  <<  6) 

#define  VtReportTBMD0bserv(2L  <<  6) 

#define  VtReportTBMDObservBO ( 3L  <<  6) 

#define  VtReportTBMDImpact (4L  <<  6)  • 

#define  VtlsReportTBMD(X) ( ( (X->mask)  &  VtReportTBMDMask)) 

#define  VtlsReportTBMDLaunch (X) ( ( (X->mask)  &  VtReportTBMDMask)  ==  VtReportTBMDLaunch) 
#define  VtlsReportTBMDObserv (X) ( ( (X->mask)  &  VtReportTBMDMask)  ==  VtReportTBMDObserv) 
#define  VtlsReportTBMDObservBO (X) ( ( (X->mask)  &  VtReportTBMDMask)  ==  VtReportTBMDObservBO) 
#define  VtlsReportTBMDImpact (X) ( ( (X->mask)  &  VtReportTBMDMask)  ==  VtReportTBMDImpact) 


//  Mask  values  for  datano  field 

#def ine  VtRepor tDa taTypeMaskOxf  0  000000 
#define  VtReportRadDataMask ( IL  <<  28) 

#define  VtReportSignaDataMask ( IL  «  29) 

#define  VtReportSIDataMask (IL  <<  30) 

#define  VtReportOtherDataMask ( IL  <<  31) 

#define  RpthasData (X) ( ( (X)  &  VtReportDataTypeMask) ) 

#define  ReporthasData (X) ( ( (X->datano)  &  VtReportDataTypeMask)) 

#define  RpthasDataNumber (X) ( ( (X)  &  -VtReportDataTypeMask)) 

#define  ReporthasDataNumber (X) ( ( (X->datano)  &  -VtReportDataTypeMask)) 

#define  RpthasRadData (X) ( ( (X)  &  VtReportDataTypeMask)  ==  VtReportRadDataMask) 

#define  ReporthasRadData (X) ( ( (X->datano)  &  VtReportDataTypeMask)  ==  VtReportRadDataMask) 
#define  RpthasSignaData (X) ( ( (X)  &  VtReportDataTypeMask)  ==  VtReportSignaDataMask) 

#define  ReporthasSignaData (X) ( ( (X->datano)  &  VtReportDataTypeMask)  ==  VtReportSignaDataMask) 
#define  RpthasSIData (X) ( ( (X)  &  VtReportDataTypeMask)  ==  VtReportSIDataMask) 

#define  ReporthasSIData (X) ( ( (X->datano)  &  VtReportDataTypeMask)  ==  VtReportSIDataMask) 
#define  RpthasOtherData (X) ( ( (X)  &  VtReportDataTypeMask)  ==  VtReportOtherDataMask) 

#define  ReporthasOtherData (X) ( ( (X->datano)  &  VtReportDataTypeMask)  ==  VtReportOtherDataMask) 


#define  VtSetReportRadData (X) ( (X)  |=  VtReportRadDataMask) 


tdefine  VtSetReportSignaData (X) ( (X)  |=  VtReportSignaDataMask) 

♦define  VtSetReportSIData (X) ( (X)  |=  VtReportSIDataMask) 

♦define  VtSetReportOtherData (X) { (X)  |=  VtReportOtherDataMask) 

♦define  VtReportDataNumber (X) ((X)  &  -VtReportDataTypeMask) 

♦define  VtSetReportDataNumber (X, Y) ( (X)  |=  ( (Y)  &  -VtReportDataTypeMask)) 

♦define  VtClearReportDataType (X) ( (X)  &=  -VtReportDataTypeMask) 

♦define  VtClearReportRadData (X) { (X)  &=  -VtReportRadDataMask) 

♦define  VtClearReportSignaData (X) ( (X)  &=  -VtReportSignaDataMask) 

♦define  VtClearReportSIData (X) ( (X)  &=  -VtReportSIDataMask) 

♦define  VtClearReportOtherData (X) ( (X)  &=  -VtReportOtherDataMask) 


typedef  struct 

A7  { 

double 

lat 

double 

lng 

float 

cse 

float 

spd 

long 

dtg 

VtAou 

aou 

}  VtShortReport; 

typedef  struct 

A8  { 

//  latitude  in  degrees 
//  longitude  in  degrees 
//  course  (DECT) 

//  speed  (KTS) 

//  Julian  seconds  since 
//  area  of  uncertainty 


1  Jan  1970 


long  dtg; 
long  nrpts; 


//  Time  of  tracker  solution 
//  Number  of  reports  for  solution 


float  lat; 
float  Ing; 
float  lat_spd; 
float  lng_spd; 
float  covtlO] ; 
float  alpha; 
float  sigma; 


//  Lat  of  tracker  solution 
//  Lng  of  tracker  solution 
//  Speed  (lat)  of  tracker  solution 
//  Speed  (lng)  of  tracker  solution 
//  Covariance  Matrix  of  tracker  solution 
//  Alpha  parameter  of  tracker  solution 
//  Sigma  parameter  of  tracker  solution 


float  cse; 
float  spd; 
float  tol; 
float  ave_spd; 


//  Computed  course 
//  Computed  speed 
//  time  on  leg  in  hours 
//  average  speed  on  leg 


)  VtTracker 


typedef  struct  A9  { 


double  pri_mean;  //  Mean  value  of  associated  pri's 

double  pri_sigma;  //  sigma  value  of  associated  pri's 

double  pri_sumsguares ; / /  sum-of -squares  value  of  associated  pri's 
long  pri_i terns; 


double  pri_sumwobs;  //  sum  weighted  observations 

double  pri_sumw;  //  sum  inverse  reported  observation  deviations 

double  pri_sLmiwsqobssq; //  sum  squared  observations  weighed  inversely  by 
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// 


reported  observation  vari 


ance 

double  pri_sumwsqobs ;  //  sum  observations  weighed  inversely  by 
//  reported  observation  variance 

double  pri_sumwsq;  //  sum  inverse  reported  observation  variance 


double 

double 

double 

long 


scan_mean;  //  mean  of  scan 

scan_sigma;  //  standard  deviation  of  scan 

scan_sumsquares; //  sum  of  squares  of  scan 
scan_items;  //  number  of  scan  items 


double  scan_sumwobs ;  //  sum  weighted  observations 

double  scan_sumw;  //  sum  inverse  reported  observation  deviations 

double  scan_sumwsqobssq; / /  sum  squared  observations  weighed  inversely  by 


ance 

// 

reported 

observation  vari 

double 

scan_sumwsqobs ; / / 

sum  observations  weighed  inversely  by 

ance 

// 

reported 

observation  vari 

double 

scan_sumwsq ;  / / 

sum  inverse  reported  observation  variance 

double 

rf_mean; 

/ /  mean  of  rf 

double 

rf_sigma; 

/ /  standard  deviation  of  rf 

double 

rf_sumsguares ;  /  / 

sum 

of  scjuares  of  rf 

long 

rf_items ; 

//  number  of  rf' items 

double 

rf_sumwobs ; 

//  sum  weighted  observations 

double 

rf_sumw; 

//  sum  inverse  reported  observation  deviations 

double 

rf_sumwsqobssq;  / / 

sum 

squared  observations  weighed  inversely  by 

ance 

// 

reported  observation 

vari 

double 

rf_sumwsqobs ;  // 

sum 

observations  weighed  inversely  by 

ance 

//  reported  observation 

vari 

double 

rf_sumwsq; 

//  sum  inverse  reported  observation  variance 

double 

rf_bcmean; 

//  mean  of  RFBCs 

)  VtElintStats  ; 


typedef  struct  AlO  { 


long 

datano ; 

//  number  of  this  rad  line  report 

long 

ctcno; 

//  Number  of  the  report  associated  with  elint 

double 

f  reg.- 

//  frequency  of  the  emitter (MHZ) 

double 

pri; 

//  pulse  repetition  interval  (micro-sec) 

double 

prf; 

//  pule  repetition  frequency  (pulses  per  sec) 

double 

pw; 

//  pulse  width  (micro-sec) 

double 

scan_rate ; 

//  scan  rate  for. radar  (SPC)  (1/HZ) 

double 

bb_pri ; 

/ /  Basebanded  pri 

double 

bb_scan_rate; 

// 

Basebanded  scan_rate 

char 

bb_pri_mode ; 

// 

Reported,  Crystal,  Range,  Adaptive 

char 

bb_scan_rate_mode 

; / /  Reported  or  Range 

char 

elnotlconf ; 

//  Primary  elnot  confidence  (NN  <  10) 

char 

elnot2conf ; 

//  Secondary  elnot  confidence  (NN  <  10) 

float 

freq_stability;// 

reported  sigma  for  RF 

float 

pri_stability; 

// 

reported  sigma  for  PRI 

float 

scan_stability 

;// 

reported  sigma  for  scan  rate 

long 

dtg; 

//  date-time-group  of  report 

long 

sen; 

//  seqtuential  contact  number 

char 

elnotl [ 6 ] ; 

//  ELINT  notation  or  name 

char 

elnot2 [6]; 

//  Secondary  elnot  [ANNNA, ANNNN,NNNAA]  ^ 

char 

ci[3]; 

//  Correlation  Index 

char 

emitter [16]  ; 

// 

emitter  name  {DON  KEY) 

char 

scan_type [ 5 ] ; 

// 

scan  type  {four  letters,  mapped  to  1  ?  ) 

char 

stagger_legs ; 

// 

stagger  legs  N 

char 

pri_type; 

//  type  of  PRI  interval 

char 

spare [ 2 ] ; 

//  spare  bytes  (pad  for  4  byte  alignment) 

}  VtRadReport 

,  VtRadData  ; 

typedef  struct 

All  { 

char 

indicator [2 ]  ; 

// 

warning  indication  A 

char 

msg_type ( 3 ] ; 

// 

Message  type 

char 

fcode (31; 

//  Force  Code  as  described  in  OTG  spec 

char 

flag [3] ; 

// 

flag  of  long  BE  (CCNNNNANNNNN) 

// 

CC  =  country  code 

char 

db_type ; 

//  database  number  type:  DB_NUM_TYPE_PIN,  ... 

char 

db_num [ 14  J ; 

//  BE  number  NNNNANNNNN 

//  NNNN  =  world  area  code 

(E) _site 

//  A  =  BE  Type  (Oomplex, 

PIN 

/  /  NNNNN  =  world  area  code 

char 

sconuiii[7]  ; 

//  tgtid  [NNNNNN.NANNNNN,  ENNNNN,  DANNNN,  DNNNNN] 

PIN 

//  PARAGON  uses  this  field  to  store 

char 

category [4] ; 

// 

category 

char 

threat [ 4 ] ; 

//  threat  class 

char 

freq_agility  ; 

// 

agility  of  RFs 

char 

spare [ 6 ] ; 

//  spare  bytes  (pad  for  4  byte  alignment) 

}  VtlllData; 

typedef  struct  A12  { 


VtReport  rpt; 
VtRadReport  rad; 
VtlllData  iii; 

)  VtlllReport  ; 


typedef  struct 

A13  { 

VtReport  rpt; 

VtRadReport  rad; 

)  VtRadAndReport ; 

typedef  struct 

A14  { 

float 

freq; 

float 

bw; 

char 

cn[VT_CN_LEN+l] 

char 

sn[VT_SN_LEN+l] 

char 

mt[VT_MT_LEN+l] 

char 

xm[VT_XM_LEN+l] 

char 

eg [VT_CG_LEN+1 ] 

char 

cl[VT_CL_LEN+l] 

char 

xc  tVT_XC_LEN+l ] 

char 

Cd [VT_CD_LEN+1 ] 

char  spare  [  4  ]  ; 

}  VtSIRptAttribData; 

typedef  struct 

A15  { 

long 

datano ; 

long 

ctcno; 

long 

quantity; 

VtSIRptAttribData 


//  byte  alignment 


/ /  index  to  SI  contact  data 
//  index  to  VtReport .ctcno 
//  number  of  items 
//  report  attribute  data 


source [VT_S0URCE_LEN+1) ; //  reported  source 
fdi [VT_FDI_LEN+1] ;  //  File  Distrib  Indicator 

pddg[VT_PDDG_LEN+l) ;  //  reported  pddg 

serial [VT_SERIAL_LEN+1] ;  //  serial  number 
msg_type [VT_MSG_TYPE_LEN+1] ;  //  Recvd  msg  type 

char  iff [VT_IFF_LEN+1J ;//  Id  Friend  or  Foe 


char 

)  VtSIReport; 


sanitizable; 


//  Is  contact  sanitizable 


typedef  struct  A16  { 

VtReport  rpt ; 
VtSIReport  si; 
}  VtSiAndReport ; 


typedef  struct  A17  { 

long  datano; 


//  index  to  Acoutsic  data 


long  ctcno; 
long  dtg; 
double  freq; 
double  freq_max; 
float  rpm; 


//  index  to  VtReport . ctcno 
//  date-time-group  of  report 

//  (minimum)  fundamental  frequency  in  HZ 
//  (maximum)  fundamental  frequency  in  HZ 
//  revolutions  per  minute 
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float  tpk; 
char  harm  [24]; 

char  source[16]; 
)  VtSignaReport ; 


/ /  turns  per  knot 
//  Harmonics 

II  source  of  information 


typedef  struct  A18  { 
VtReport  rpt; 
VtSignaReport  signa; 
}  VtSignaAndReport ; 


#define  VT_TLEVEL_CASE  1 
tdefine  VT_TLEVEL_DSUB  1 
#define  VT_TLEVEL_DES IG  2 
# define  VT_TLEVEL_TGT  3 
tdefine  VT_TLEVEL_CONT  4 
#define  VT_TLEVEL_POD  4 
#define  VT_TLEVEL_UNKNOWN  4 


typedef  struct  A19  { 


long 

long 

long 

char 

char 

char 

char 

char 

char 

char 

char 

char 

char 

char 

char 

char 

char 

char 

char 

char 

char 

char 

char 


etd; 
eta; 
arrdtg; 
appgrp[7] ; 
hullprof (13 ] 
stern [9] ; 
uprights [13] 
prop [ 6 ] ; 
tonnage [ 7 ] ; 
length [5] ; 
beam [ 5 ] ; 
draft [3]  ; 
blades [3] ; 
shafts [3] ; 
depport [19 ] ; 
depflag[3] ; 
desport [19 ] ; 
desflag[3] ; 
arrport [ 19 ]  ; 
arrf lag [ 3 ] ; 
dep_cargo [ 4 ] 
des_cargo [ 4 ] 


arr_cargo [ 4 ] [ 4 ] 


}  VtTechData; 


typedef  struct  A20  { 
char  cmd[15]; 
char  line [4 ] [ 65 ] ; // 
char  spare [51; 

)  VtRemarks ; 


/ /  command  from  which  remarks  came 
four  remarks  lines 
//  byte  alignment 


typedef  struct  A21  { 
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long  num;  //  current  number  in  rmks [ ]  array 

long  size;  //  current  size  of  rmks  array 

VtRemarks  rmks;//  array  of  pointers  to  remarks  WAS  **rmks 
)  VtRcvdRemarks ; 


typedef  struct  A22  { 
long  trkrec ; 
long  tm_dif; 
short  dist_dif; 
short  spd_reqd; 
short  cse_reqd; 
short  ascr; 
short  pscr; 
short  pri_scr; 
short  scan_scr; 
short  rf_scr; 

)  VtCandidate ; 


//  candidate  track  number 
//  calculated  time  difference 
//  calculated  dist  difference 
//  speed  required  to  position 
//  cse  required  to  position 

//  attribute  score  -100  to  100 
//  position  score  -100  to  100 
//  PRI  score  -100  to  100 
//  Scan  rate  score  -100  to  100 
//  RF  score  -100  to  100 


typedef  struct  A23  { 

VtCandidate  track [7] ; 
)  VtCandidateList ; 


typedef  struct  A24  { 
long  dtg; 
short  state; 
char  trknum[7] ; 
char  cmd[151 ; 

}  VtTrknum; 


//  dtg  of  associated  POS 
//  RTN  state  (spare) 

//  Track  Number  string 
//  Source  command  of  tr)cnum 


//  VtTr)mum  state  values  for  RTN  priority  order:  Fotc,  Copy  then  Local 


#define  VtTr)cnumFotcRTN2 
#define  VtTr)mumCopyRTNl 
#define  VtTrknumLocalRTNO 


typedef  struct  A25  { 
long  type; 
long  trkrec; 
long  source; 
long  assoc; 

9  long  child; 

long  machine; 
char  serial[20]; 
char  ltn[8]; 

)  VtTrackHeader ; 


//  Type  of  track 

//  Record  of  track 

//  Source  bit  mask 

//  Associated  trkrec 

//  child  trkrec  (conditionally) 

//  Machine  mask  for  Local  tracks  bits  0-31 
//  Unique  identifier 

/ /  Local  Track  Number 

//  Software  Version  (future) 


typedef  struct  A26  { 

VtTrknum  ftn;  //  FOTC  Track  Number 

VtTrknum  rtn [VT_MAX_RTN1 ; //  Array  of  Rcvd  Track  Numbers 

9  char  ltn[7];  //  Local  Track  Number 
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char 

shipclass  [  12 ]  ; 

// 

class  of  ship 

char 

name [27] ; 

//  name  of  the  track 

char 

trademark [21] ; 

// 

trademark 

char 

type [ 7 ] ; 

// 

type  of  ship  (i.e.  DDG,  CVN) 

char 

hull [7] ; 

//  hull  number  of  ship 

char 

flag[3] ; 

// 

flag  of  fft 

char 

sconum [ 7 ] ; 

//  NOSIC  ID 

char 

pif [5]  ; 

//  pif  as  reported  by  intel 

char 

ntds [ 6 ] ; 

//  ntds  track  number  if  associated 

char 

di[5] ; 

//  discrete  identifier 

char 

callsign [9 ] ; 

// 

call  sign  of  last  entered  call  sign 

char 

uic[7] ; 

//  Unit  Identification  Code 

char 

elnot [6] ; 

//  elnot 

char 

emitter [16] ; 

// 

Emitter  name 

char 

alert [4 ] ; 

//  alert  class  of  track  (HIT,TGT) 

char 

category [4] ; 

// 

Category  (NAV,AIR,  etc.) 

char 

threat [ 4 ] ; 

//  Threat  class 

char 

xref [5] ; 

char 

chxref [4] ; 

//  input  channel  cross-reference 

char 

shortname [11] ; 

// 

Symbol  Annotation 

}  VtTrackSearch; 


typedef  struct  A27  { 

VtTrknum  ftn;  //  FOTC  Track  Number 

VtTrknum  rtn [VT_MAX_RTN] ; / /  Array  with  up  to  12  Rcvd  Track  Number 


char 

shipclass [ 12 ] ; 

// 

class  of  ship 

char 

name [27] ; 

//  name  of  the  track 

char 

trademark [21] ; 

// 

trademark 

char 

type [7] ; 

// 

type  of  ship  (i.e.  DDG,  CVN) 

char 

hull [7] ; 

//  hull  number  of  ship 

char 

flag [3] ; 

// 

flag  of  fft 

char 

sconum [7] ; 

//  NOSIC  ID 

char 

pif [5] ; 

//  pif  as  reported  by  intel 

char 

ntds [ 6 ] ; 

//  ntds  track  number  if  associated 

char 

di[5]  ; 

//  discrete  identifier 

char 

callsign [9 ] ; 

// 

call  sign  of  last  entered  call  sign 

char 

uic  [7]; 

//  Unit  Identification  Code 

long 

quantity; 

/ /  number  in  track 

char  home_base[21] ;  //  home  base/port 

char  db_type;  //  database  number  type:  DB_NUM_TyPE_PIN,  ... 

char  db_num[14]; 


(E)_site 

PIN 


/ /  BE  number  NNNNANNNNN 
/  /  NNNN  =  world  area  code 

//  A  =  BE  Type  (C)omplex, 

//  NNNNN  =  world  area  code 


//  alert  class  of  track  (HIT,TGT) 

/ /  Force  Code  as  described  in  BGDBM  spec 
//  Category  (NAV,AIR,  etc.) 


char  alert [4 ] ; 
char  fcode[3]; 
char  category [4] 


char  threat[4]; 
char  shortname [111 ; 
char  xref [5] ; 
char  orig_xref [5] ; 
char  chxref[4]; 

double  latfixed; 
double  Ing fixed ; 

}  VtPlatfonnData; 


typedef  struct 

A28  { 

double 

lat  ; 

//  latitude  in  degrees 

double 

Ing; 

//  longitude  in  degrees 

float 

cse; 

//  course  (DECT) 

float 

spd; 

//  speed  (KTS) 

float 

alt; 

//  altitude  (+FT/-FT) 

float 

anglelv; 

//  angle  of  elevation/depression 

long 

dtg; 

//  Julian  seconds  since  1  Jan  1970 

unsigned  short  mask;//  mask  (see  VtReport) 

char  db_type;  //  database  number  type:  DB_NUM_TYPE_PIN, 

char  db_num[14]; 

}  VtTBMData; 


//  Threat  class 
//  Symbol  Annotation 

//  input  channel  cross-reference 


typedef  struct  A29  { 

long  type;  //  LINKll  data  types  (0-15) 

long  nbytes;  //  number  of  link_data 

bytes 

unsigned  long  link_data[VT_MAX_LRAW] ; //  Link  data  msg  buffer 
)  VtRawData,  LRAWDATA; 


typedef  struct  A30  { 


long  ■ 

updates ; 

// 

number 

of  times  track  has  been  updated 

long 

tkno; 

// 

last  received  track  number 

short 

link; 

// 

Link  block  LINK_A,  . . .  LINK_D 

short 

quality; 

// 

track  quality 

short 

ru; 

// 

reporting  unit 

short 

di  ; 

// 

pif  as  reported  by  link 

short 

ctsx  ; 

short 

local_quality ; 

short 

engagement ; 

short 

spare ; 

// 

spare  element 

short 

modelif f ; 

// 

Mode  1 

as  reported  by  link 

short 

mode2if  f  ; 

// 

Mode  2 

as  reported  by  link 

short 

model if f ; 

// 

Mode  3 

as  reported  by  link 

short 

mode4iff ; 

// 

Mode  4 

as  reported  by  link 

char  ( 

threat [ 4 ] ; 

// 

threat 

class  F,  H,  AF,  AE,  . . 

char  category [4] ; 
char  alert [4 J; 
char  shortname [ 11] ; 
char  xref[5]; 
VtRawData  Irawdata; 


//  category  NAV,  SUB,  ... 

//  Alert 

//  Symbol  Annotation 
/ /  Source  xref 

//  ACDS,  Linkll  or  Linkl6  specific  data 


}  VtLinkData; 


typedef  struct  A31  { 


long  fcsno; 
char  fcspfx; 
char  status_mask; 
// 

// 

// 

// 

// 

// 


//  FCS  track  number 


//  FCS  track  prefix  S, 
//  target  status  mask: 


V,  C,  .  .  . 

bit  0  engage 
bit  1  avoid 
bit  2  CST 
bit  3  spare 

bit  4-5  weapon  selection  10-3] 
bit  6-7  spare 


char  tktype ; 
char  weather; 


//  FCS  NTDS-like  track  type 

//  weather  in  vicinity  of  target  UNKNOWN,  CLEAR,  RAIN 


char  threat[4]; 
char  category [4] ; 
char  alert [4 ] ; 
char  shortname [ 11 ] ; 
char  xref [5]; 


//  threat  class  F,  H,  AF,  AE, 
//  category  NAV,  SUB,  . . . 

//  Alert 

//  Symbol  Annotation 
//  Source  xref 


)  VtFCSData; 

#de  f ine  VtFCSWthrUnk ( 0 ) 

#define  VtFCSWthrClr ( 1) 

#define  VtFCSWthrRain (2 ) 

tdefine  VtFCSEngageMask  (1) 
tdefine  VtFCSAvoidMask ( 1  «  1) 
#define  VtFCSCstMask ( 1  «  2) 
#define  VtFCSWeaponMask (3  «  4) 


tdefine  VtSetFCSEngage (X) ( (X)  |=  VtFCSEngageMask) 

#define  VtSetFCSAvoid (X) ( (X)  |=  VtFCSAvoidMask) 

#define  VtSetFCSCst (X)  ((X)  |=  VtFCSCstMask) 

#define  VtSetFCSWeapon(X, Y) { (X)  =  ((X)  &  -VtFCSWeaponMask) 


I  (  (Y)  «  4)  ) 


#define  VtClearFCSEngage (X) ( (X)  &=  -VtFCSEngageMask) 
#define  VtClearFCSAvoid (X) ( (X)  &=  -VtFCSAvoidMask) 
#define  VtClearFCSCst (X) ( (X)  &=  -VtFCSCstMask) 
#define  VtClearFCSWeapon (X) ( (X)  &=  -VtFCSWeaponMask) 


#define  isFCSEngage (X)  ((X)  &  VtFCSEngageMask) 

♦define  isFCSAvoid (X)  ((X)  &  VtFCSAvoidMask) 

♦define  isFCSCst(X)  ((X)  &  VtFCSCstMask) 

♦define  VtFCSWeapon (X)  (((X)  &  VtFCSWeaponMask)  »  4) 
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typedef  struct  A32  { 


char  local_tn[6] ; 
char  system_tn[6] ; 

char  name [27] ; 

char  threat [ 4 ] ; 
char  category [ 4 ] ; 
char  alert [4]; 
char  shortname [ 11 ] ; 
char  xref(5]; 

)  VtSpa25Data; 


typedef  struct  A3 3  { 

char  local_tn(6] ; 
char  name [27] ; 

char  threat[4];  //  threat  class  F,  H,  AF,  AE,  .. 

char  category [4] ;  //  category  NAV,  SUB,  ... 

char  alert[41;  //  Alert 

char  shortname [ 11) ;  //  Symbol  Annotation 

char  xref[5];  //  Source  xref 

float  cpa_dist; 
long  cpa_dtg; 

)  VtRaycasVData ; 


//  threat  class  F,  H,  AF,  AE,  . . 
//  category  NAV,  SUB,  . . . 

//  Alert 

//  Symbol  Annotation 
//  Source  xref 


typedef  struct  A34  { 

long  updates ; 
short  link; 
short  tkno; 
short  quality; 
short  ru ; 
short  di ; 
short  modeliff; 
short  mode2iff; 
short  modeliff; 
short  mode4iff; 

char  threat [ 4 ] ; 
char  category [ 4 ] ; 
char  alert [4 ] ; 
char  shortname [11] ; 
char  xref [5 ] ; 


/ /  number  of  times  track  has  been  updated 
//  Link  block  LINK_A,  . . .  LINK_D 
//  last  received  track  number 
//  track  quality 

//  reporting  unit 
//  pif  as  reported  by  link 
//  pif  as  reported  by  link 
//  pif  as  reported  by  link 
//  pif  as  reported  by  link 
//  pif  as  reported  by  link 

//  threat  class  F,  H,  AF,  AE,  . . 

//  category  NAV,  SUB,  ... 

/ /  Alert 

//  Symbol  Annotation 
//  Source  xref 


)  VtLateralTellData ; 


typedef  struct  A35  { 


VtElintStats  stats; 

char  emitter [16) ; 

char  elnotl[6]; 
char  elnotlconf; 
char  elnot2[6]; 
char  elnot2conf; 

char  flag[3]; 

char  db_type; 
char  db_nuin[14]  ; 


(E)_site 

PIN 

char  sconum[7]; 

PIN 

char  alert [4]; 
char  f code (3); 
char  category [ 4 1 ; 
char  threat [4]; 
char  shortname [11] ; 
char  xref(51; 
char  orig_xref [5] ; 
char  chxref[4]; 

}  VtEmitterData,  VtElintData; 


typedef  struct  A36  { 

char  trademark [21 ] ; 
char  shipclass [ 12 ] ; 

char  prop [ 6 ] ; 
char  sconum[7]; 

PIN 

char  flag[3]; 
char  type [ 7 ] ; 

char  alert [4]; 
char  f code [3]; 
char  category [4]; 
char  threat [4]; 
char  shortname [ 11 ) ; 
char  xref [ 5 ]  ; 


//  Ellong  statistics 

//  Emitter  name  (DON  KAY) 

//  Primary  elnot  [ANNNA, ANNNN,NNNAA] 

//  Primary  elnot  confidence  (NN  <  10) 

//  Secondary  elnot  [ANNNA, ANNNN,NNNAA] 

//  Secondary  elnot  confidence  (NN  <  10) 

//  flag  of  long  BE  (CCNNNNANNNNN) 

//  CC  =  country  code 

//  database  number  type;  DB_NUM_TYPE_PIN,  ... 


//BE  number  NNNNANNNNN 
//  NNNN  =  world  area  code 

//  A  =  BE  Type  (C)omplex, 

//  NNNNN  =  world  area  code 


//  tgtid  [NNNNNN.NANNNNN,  ENNNNN,  DANNNN,  DNNNNN] 

//  PARAGON  uses  this  field  to  store 


//  alert  class  of  track  (HIT,TGT) 

//  Force  Code  as  described  in  BGDBM  spec 
//  Category  (NAV.AIR,  etc.) 

//  Threat  class 
//  Symbol  Annotation 


//  input  channel  cross-reference 


//  Trademark  of  sub 
//  Class  of  sub 

//  propulsion  NUC,  UNK,  DES 

//  tgtid  (NNNNNN.NANNNNN,  ENNNNN,  DANNNN,  DNNNNN] 

//  PARAGON  uses  this  field  to  store 


//  flag  of  fft 


//  alert  class  of  track  (HIT.TGT) 

//  Force  Code  as  described  in  BGDBM  spec 
//  Category  (NAV.AIR,  etc.) 

//  Threat  class 
//  Symbol  Annotation 


char  chxref[4]; 


//  input  channel  cross-reference 


}  VtAcousticData; 


typedef  struct  A37  { 


char  name [39] ; 


KER,  APRON, 


//  Name  from  NIPS  displayed  as  26  char  string 

//  Include  ???:  subject [41]  -  BUN- 


char  flag[3]; 


//  flag  of  long  BE  (CCNNNNANNNNN) 


char  db_type; 
char  db_num[141 


(E)_site 


char  f unci [6]; 

ligence  File) 
char  status[4]; 
char  function [3]; 
char  radius [ 5 ] ; 


//  database  number  type:  DB_NUM_TYPE_PIN,  ... 

/ /  BE  number  NNNNANNNNN 
//  NNNN  =  world  area  code 

//  A  =  BE  Type  (C)omplex, 

/  /  NNNNN  =  world  area  code 

//  Fund  code  for  site  NNNNN  (a)ta  NIPS  CATEGORY) 

//  from  the  AIF  (Automated  Intel- 

//  Site  Status 

//  Site  function  (AA:  RadarFuncDefaults .h) 

//  Site  Radius  NNNN 


char  source_data [ 8 ] ; / /  Source  data 


char  alert  [4]; 
char  f code [3]; 
char  category [4] ; 
char  threat [ 4 ] ; 
char  shortnaime  [11  ]  , 
char  xref [5] ; 
char  orig_xref [51 ; 
char  chxref[41; 


//  alert  class  of  trac)c  (HIT,TGT) 

//  Force  Code  as  described  in  BGDBM  spec 
//  Category  (NAV,AIR,  etc.) 

//  Threat  class 
/ /  Symbol  Annotation 


//  input  channel  cross-reference 


)  VtLandData ; 


typedef  struct  A3  8  { 


VtTrknum  r tn  [  VT_MAX_RTN  ]  ;  /  /  Array  of  Rcvd  Track  Niimbers 


char  name [31] 


char  uic [ 7 ] ; 
char  echelon [8]; 
char  service [4]; 
char  platform[7]; 
char  strength[4]; 
char  org_type [ 9 ] ; 
char  embarked [31] 


//  Unit  Ident  Code 
//  Echelon  ???  chars 
//  Service  ???  chars 
//  Platform  ???  chars 
//  Force  strength  ???  chars 
//  Organization  Type  ???  chars 


char  flag[3]; 
char  type [ 7 ] ; 


//  flag  of  fft 

//  type  as  in  MAU  etc 
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//  Symbol  Annotation 


char  shortname [ 11] ; 
char  category [4]; 
char  threat [ 4 ] ; 
char  alert (4]; 
char  f code [3]; 
char  track_type ; 
char  xref [5] ; 
char  orig_xref [5] ; 
char  chxref[4]; 

)  VtUnitData; 


//  alert  class  of  track  (HIT.TGT) 

//  Force  Code  as  described  in  BGDBM  spec 


//  input  channel  cross-reference 


typedef  struct  A3  9  { 


char  local_tn [ 6 ] ; 
char  name [27]; 
char  alert [4]; 
char  f code [31; 
char  category [4]; 
char  threat [4]; 
char  shortname [11] ; 
char  xref [5]; 
char  chxref[4]; 


//  Optional,  but  likely  to  be  useful 
//  Optional,  but  likely  to  be  useful 

//  Alert  ® 

//  Force  Code  as  described  in  BGDBM  spec 
//  Category  (NAV,AIR,  etc.) 

//  Threat  class 
//  Symbol  Annotation 

/ /  input  channel  cross-reference  A 


}  VtMinExtData; 


struct 

> 

O 

long 

si_id; 

//  Unique  SI  identifii 

long 

quantity; 

//  number  in  track 

char 

flag[VT_FLAG_LEN+l] ; 

//  flag 

char 

threat [VT_THREAT_LEN+1] ; 

//  threat  class 

char 

category [VT_CATEG0RY_LEN+1 ] ; 

//  category  (AIR,  NAV) 

char 

native_type[VT_NTYPE_LEN+l] ; 

//  native  type  xlation 

char 

class [VT_CLASS_LEN+1] ; 

//  shipclass  or 

//  aircraft  type 

char 

hull  [VT_HULL_LEN+1]  ; 

//  hull  number  of  ship 

char 

fcode [VT_FCODE_LEN+l ]  ; 

//  force  code 

char 

home_base [VT_H0ME_BASE_LEN+1] ; 

//  home  base /port 

char 

op_subord [VT_SUB0RD_LEN+1] ; 

//  operational  subord 

char 

admin_subord [VT_SUB0RD_LEN+1 ] ; 

//  admin  subord 

char 

callsign [VT_CALLSIGN_LEN+1] ; 

//  track's  callsign 

//  or  callword 

char 

subj_type [ VT_SUB J_T YPE_LEN+ 1 ] ; 

//  Subject  type 

char 

raid  [VT_RAID_LEN+1  ]  ;  /  /  raid  n\iinber 

char 

pddg[VT_PDDG_LEN+l] ; 

//  pddg 

char 

suffix[VT_SUFFIX_LEN+l] ; 

//  suffix 

char 

alert_word  [VT_ALERT_W0RD_LEN+1  ] 

;  //  alert  word 

}  VtSIData; 


char 

xref [VT_XREF_LEN+1] ; 

char 

chxref [VT_CHXREF_LEN+1] ; //  channel  xref 

char 

shortname [ VT_SHORTNAME_LEN+ 1 ] ; / /  Symbol 

Annotation 

char 

spare [ 3 ] ; 

/ /  byte 
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typedef  struct  A41  { 


VtTrackHeader  hdr;  //  Track  Header 
VtTrackStatus  trkstat;//  Track  status 

VtTracker  state;  //  Tracker  state  at  time  of  last  report 

VtReport  rpt;  //  Last  Associated  report 

VtPlatf ormData  data;//  Data  associated  with  platform  tracks 

}  VtPlatformTrack,  VtPTrack; 


typedef  struct  A42  { 

VtTrackHeader  hdr;  //  Track  Header 
VtTrackStatus  trkstat;//  Track  status 

VtTracker  state;  //  Tracker  state  at  time  of  last  report 

VtReport  rpt;  //  Last  Associated  report 

VtLinkData  data;  //  Data  Associated  with  Link  Track 

}  VtLinkTrack,  VtLTrack; 


typedef  struct  A43  { 

VtTrackHeader  hdr;  //  Track  Header 
VtTrackStatus  trkstat;//  Track  status 

VtTracker  state;  //  Tracker  state  at  time  of  last  report 

VtReport  rpt;  //  Last  Associated  report 

VtFCSData  data;  //  Data  Associated  with  PCS  Track 

}  VtFCSTrack,  VtFTrack; 


typedef  struct  A44  { 

VtTrackHeader  hdr;  //  Track  Header 
VtTrackStatus  trkstat;//  Track  status 

VtTracker  state;  //  Tracker  state  at  time  of  last  report 

VtReport  rpt;  //  Last  Associated  report 

VtSpa25Data  data;  //  Data  Associated  with  Link  Track 

)  VtSpa25Track,  VtSTrack; 


typedef  struct  A45  { 

VtTrackHeader  hdr;  //  Track  Header 
VtTrackStatus  trkstat;//  Track  status 

VtTracker  state;  //  Tracker  state  at  time  of  last  report 

VtReport  rpt;  //  Last  Associated  report 

VtRaycasVData  data;  //  Data  Associated  with  Link  Track 

}  VtRaycasVTrack,  VtRTrack; 


typedef  struct  A46  { 


VtTrackHeader  hdr;  //  Track  Header 

VtTrackStatus  trkstat;//  Track  status 

VtTracker  state;  //  Tracker  state  at  time  of  last  report 

VtReport  rpt;  //  Last  Associated  report 

VtLateralTellData  data;//  Data  Associated  with  Link  Track 

}  VtLateralTellTrack,  VtTTrack; 


typedef  struct  A47  { 

VtTrackHeader  hdr ;  /  /  Track  Header 

VtTrackStatus  trkstat;//  Track  status 

VtTracker  state;  //  Tracker  state  at  time  of  last  report 

VtReport  rpt;  //  Last  Associated  report 

VtRadReport  rad;  //  Last  Associated  Rad  data 

VtEmitterData  data;  //  Emitter  attributes 


)  VtEmitterTrack,  VtETrack; 


typedef  struct  A48  { 

VtTrackHeader  hdr ;  /  /  Track  Header 

VtTrackStatus  trkstat;//  Track  status 

VtTracker  state;  //  Tracker  state  at  time  of  last  report 

VtReport  rpt;  //  Last  Associated  report 

VtSignaReportsigna;  //  Last  reported  Signa  data 
VtAcousticData  data;//  Acoustic  attributes 

}  VtAcousticTrack,  VtATrack; 


typedef  struct  A49  { 

VtTrackHeader  hdr;  //  Track  Header 

VtTrackStatus  trkstat;//  Track  status 

VtTracker  state;  //  Tracker  state  at  time  of  last  report 

VtReport  rpt;  //  Last  Lcind  report 

VtLandData  data;  //  Land  attributes 

}  VtLandTrack,  VtGroundTrack, VtGTrack; 


typedef  struct  A50  { 

VtTrackHeader  hdr;  //  Track  Header 

VtTrackStatus  trkstat;//  Track  status 

VtTracker  state;  //  Tracker  state  at  time  of  last  report 

VtReport  rpt;  //  Last  Land  report 

VtUnitData  data;  //  Land  attributes 


)  VtUnitTrack,  VtUTrack; 


typedef  struct  A51  { 


VtTrackHeader  hdr;  //  Track  Header 

VtTrackStatus  trkstat;//  Track  status 

VtTracker  state;  //  Tracker  state  at  time  of  last  report 

VtReport  rpt;  //  Last  Associated  report 

VtSIReport  sirpt;  //  SI  Data  from  last  report 

VtSIData  data;  //  single  source  track 

)  VtSITrack,  VtCTrack; 


//=  =  =  =  ^  =  =  =  =  =  =  =  =  =  =  =:  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  ===  =  =  =  =  = 
//============================================================ 

typedef  struct  A52  { 

VtTrac3cHeader  hdr;  //  Common  Track  Header 
VtTrackStatus  trkstat;//  Common  Track  status 

VtTracker  state;  //  Common  Tracker  state  at  time  of  last  rpt 

VtReport  rpt;  //  Common  Last  report 

VtMinExtData  data;  //  Mostly  Common  data 
char  pad [554];  //  VT_MAX_TRACK_SIZE  - 

//  sizeof (VtTrackHeader)  - 
//  sizeof (VtTrackStatus)  - 
//  sizeof (VtTracker)  - 
//  sizeof (VtReport)  - 

//  sizeof (VtMinExtData) ]; //  Remaining  space  to  be  defined  seperately 
}  VtExtTdbmTrack,  VtXTrack; 


typedef  struct  A53  { 

char  pad[VT_MAX_TRACK_SIZE} ; 
}  VtGenericTrack; 


union  VtTrack  switch  (long)  { 


case  1:  VtGenericTrac)cntrk; 
case  2  ;  VtTrac)tHeaderhdr  ; 
case  3 :  VtPlatf ormTrackptrk; 
case  4:  VtEmitterTracketrk; 
case  5:  VtAcousticTrackatrk; 
case  6:  VtSpa25Trackstrk; 
case  7 :  VtLateralTellTrackttrk; 


case 

8: 

VtRaycasVTrackr tr k ; 

case 

9: 

VtUnitTrack 

utrk 

case 

10 

VtLandTrack 

gtrk 

case 

11 

VtSITrack 

ctrk 

case 

12 

VtLinkTrack 

Itrk 

case 

13 

VtFCSTrack 

ftrk 

case 

14 

:  VtExtTdbmTrackxtrk 

//  VtTrack  union  types 


♦define  VtNoTrackTypeO 


♦define  VtPlatf ormTrackTypel 
♦define  VtEmitterTrackType2 
♦define  VtAcousticTrackType3 
♦define  VtSpa25TrackType4 
♦define  VtLateralTellTrackTypeS 
♦define  VtRaycasVTrackType6 
♦define  VtUnitTrackType? 

♦define  VtLandTrackTypeS 
♦define  VtFCSTrackType  8 
♦define  VtSITrackType  9 
♦define  VtLinkTrackTypelO 
♦define  VtExternalTrackTypell 

♦define  VtNTrkVtNoTrackType 

♦define  VtPTrkVtPlatformTrackType 
♦define  VtETrkVtEmitterTrackType 
♦define  VtATrkVtAcousticTrackType 
♦define  VtSTrkVtSpa25TrackType 
♦define  VtTTrkVtLateralTellTrackType 
♦define  VtRTrkVtRaycasVTrackType 
♦define  VtUTrkVtUnitTrackType 
♦define  VtGTrkVtLandTrackType 
♦define  VtFTrkVtFCSTrackType 
♦define  VtCTrkVtSITrackType 
♦define  VtLTrkVtLinkTrackType 
♦define  VtXTrkVtExternalTrackType 

♦define  MAX_TYPE_INDICATORS  12 

interface  Trax2  { 

void  print  (  in  long  signal  ) ; 

void  get  {  in  long  index,  out  VtPlatformTrack  track,  out  double  time  ) ; 
); 


C.4  PROCEDURE  CALL  TIMING 


//  Client. C 

♦include  <stream.h> 

//  for  extern  "exit" 
♦include  <stdlib.h> 

//  for  timing 
♦include  <sys/time.h> 
double  xtime=l; 
double  gtime ( )  { 
return  xtime; 

} 


int  main  (int  argc,  char  **argv)  { 


long  value  =  0; 

hrtime_t  start_hires,  end_hires,  diff_hires,  Svr_time[ 15000] ; 
double  time; 


start_hires  =  gethrtime ( ) ; 
for (value=0 ;value<1000000000;  value++)  { 
diff_hires  =  gtimeO; 

}; 

end_hires  =  gethrtime ( ) ; 

cout  «  setprecision ( 16 )  «  start_hires  «  ”  to  "  <<  end_hires 

«  endl ; 

} 

C.5  NULL  PROCEDURE  TIMING 


//  client. C 

#include  <stream.h> 

//  for  extern  “exit” 
iinclude  <stdlib.h> 

//  for  timing 
# include  <sys/time.h> 
double  xtime=l; 
double  gtimeO  { 
return  xtime; 

} 

void  gx ( )  {  } 


int  main  (int  argc,  char  »*argv)  { 
long  value  =  0; 

hrtime_t  start_hires,  end_hires,  diff_hires,  Svr_time [ 15000 ] ; 
double  time; 


start_hires  =  gethrtime () ; 
for (value=0 ; value<1000000000 ; value++)  { 
gx  ( )  ; 

); 

end_hires  =  gethrtime(); 

cout  «  setprecision ( 16 )  «  start_hires  «  "  to  "  <<  end_hires 

<<  endl; 

} 


C.6  NULL  LOOP  TIMING 


//  client. C 

#include  <stream.h> 

//  for  extern  “exit" 
#include  <stdlib.h> 
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/ /  for  timing 
tinclude  <sys/time.h> 
double  xtime=l; 
double  gtime ( )  { 
return  xtime; 

) 

int  main  (int  argc,  char  **argv)  { 
long  value  =  0; 

hrtime_t  start_hires,  end_hires,  diff_hireE,  Svr_time [15000] ; 
double  time; 


start_hires  =  gethrtime ( ) ; 

for (value=0 ;value<1000000000 ; value++)  { 

); 

end_hires  =  gethrtime ( ) ; 

cout  «  setprecision(16)  <<  start_hires  «  ”  to  "  «  end_hires 

«  endl ; 

} 


C-40 


REPORT  DOCUMENTATION  PAGE 


Form  Approved 
0MB  No.  0704-0188 


Public  reponing  burden  for  this  collection  of  information  is  estimated  to  average  1  hour  per  response,  including  the  time  for  reviewing  instructions,  searching  existing  data  sources, 
gathering  and  maintaining  the  data  needed,  and  completing  and  reviewing  the  collection  of  information.  Send  comments  regarding  this  burden  estimate  or  any  other  aspect  of  this 
collection  of  information,  including  suggestions  for  reducing  this  burden,  to  Washington  Headquarters  Services.  Directorate  for  Information  Operations  and  Reports,  1215  Jefferson 
Davis  Highway,  Suite  1204,  Arlington,  VA  222024302,  and  to  the  Office  of  Management  and  Budget,  Paperwork  Reduction  Project  (0704-0188),  Washington.  DC  20503. 


1.  AGENCY  USE  ONLY  (Leave  blank) 


2.  REPORT  DATE 


Febniary  1997 


3.  REPORT  TYPE  AND  DATES  COVERED 

Final 


4.  TITLE  AND  SUBTITLE 


Predicting  CORBA  Performance  Through  Prototyping 


6.  AUTHOR(S) 

Edward  A.  Feustel,  Clyde  G.  Rohy 


5.  FUNDING  NUMBERS 

DASW01-94-C-0054 
Task  Order  T-S5-1446 


7.  PERFORMING  ORGANIZATION  NAME(S)  AND  ADDRESS{ES) 

Institute  for  Defense  Analyses  (IDA) 

1801  N.  Beauregard  St. 

Alexandria,  VA  2231 1-1772 


8.  PERFORMING  ORGANIZATION  REPORT 
NUMBER 


IDA  Paper  P-3327 


9.  SPONSORING/MONITORING  AGENCY  NAME(S)  AND  ADDRESS(ES) 

Defense  Information  Systems  Agency 
Center  for  Computer  Systems  Engineering 
5600  Columbia  Pike 
Falls  Church,  VA  2204 1-2717 


10.  SPONSORING/MONITORING  AGENCY 
REPORT  NUMBER 


I2a.  DISTRIBUTION/AVAILABILITY  STATEMENT 


Approved  for  public  release;  unlimited  distribution:  18  September  1997. 


12b.  DISTRIBUTION  CODE 

2A 


13.  ABSTRACT  (Maximum  200  words) 

This  paper  describes  experiments  that  show  how  the  results  of  simple  measurements  can  be  used  to 
design  Comdex  distributed  applications.  The  ex^riments  used  IONA  Orbix,  an  Object  Request 
Broker  (O^)  that  is  Common  Object  Request  Broker  Architecture  (CORBA)  compliant.  The 
experiments  were  conducted  on  Sun  Sparc  20s  and  Intel  Pentium  90s  using  the  Microsoft  NT  4.0 
operating  system.  The  purpose  of  the  experiments  was  to  obtain  information  about  resource 
expenditures  needed  to  support  distributedT  computing  and  to  use  that  information  to  support 
development  methodologies  for  distributed  applications.  The  p^er  shows  why  a  simple  division  of 
a  replacement  for  the  Global  Command  and  Control  System’s  Track  Correlation  application  into  a 
specific  Client  and  Server  has  little  chance  of  success.  A  worked-out  example  experiment,  using  C++, 
and  outlines  of  similar  experiments  which  should  be  performed  prior  to  the  development  of  any 
distributed  applications  are  also  provided. 


14.  SUBJECT  TERMS 

Distributed  Applications;  Design;  Timing  Models;  CORBA;  Object  Request 
Broker;  DCE,  ORBIX,  GCCS,  Track  Correlation. 


15.  NUMBER  OF  PAGES 

114 


16.  PRICE  CODE 


17.  SECURITY  CLASSIFICATION  I  18.  SECURITY  CLASSIFICATION  19.  SECURITY  CLASSIFICATION  20.  LIMITATION  OF  ABSTRACT 


OF  REPORT 
Unclassified 


NSN  7540-01-280-5500 


OF  THIS  PAGE 
Unclassified 


OF  ABSTRACT 
Unclassified 


Standard  Form  298  (Rev.  2-89) 
Prescribed  by  ANSI  Std.  Z39-18 
298-102 


